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Chapter 1: About Advanced Networking 



Volume 5: Advanced Netivorking discusses networking tasks that are not required 
in every environment, such as: 

□ WAN Optimization, which enables you to optimize environments with 
application delivery networks (ADNs). 

□ TCP/IP settings. 

□ Forwarding, which allows you to define the hosts and groups of hosts to 
which client requests can be redirected. 

□ Health Checks, which reports on the health of upstream hosts. 



About This Book 

This book is organized into the following chapters: 



a 

a 

□ 

□ 

a 

a 

a 



Chapter 2 

Chapter 3 

Chapter 4 

Chapter 5 

Chapter 6 

Chapter 7 

Chapter 8 
131 



"Configuring an Application Delivery Network" on page 17 

"Preventing Denial of Service Attacks" on page 79 

"TCP Connection Forwarding" on page 85 

"Bandwidth Management" on page 93 

"Authenticating a ProxySG" on page 115 

"Configuring Failover" on page 125 

"Configuring the Upstream Network Environment" on page 



□ Chapter 9: "Internet Caching Protocol (ICP) Configuration" on page 153 

□ Chapter 10: "Managing Routing Information Protocols (RIP)" on page 161 

□ Chapter 11: "Configuring the ProxySG as a Session Monitor" on page 167 

□ Chapter 12: "Accelerating and Controlling Micro-Branch and Mobile User 
Connections (ProxyClient)" on page 173 

□ Chapter 13: "SOCKS Gateway Configuration" on page 327 

□ Chapter 14: "Verifying the Health of Services Configured on the ProxySG" 
on page 345 

□ Chapter 15: "TCP/IP Configuration" on page 405 

□ Chapter 16: "Virtual IP Addresses" on page 409 

□ Chapter 17: "WCCP Settings" on page 411 

□ Appendix A: "Using Policy to Manage Forwarding" on page 419 
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Document Conventions 

The following table lists the typographical and Command Line Interface (CLI) 
syntax conventions used in this manual. 



Table 1-1 Document Conventions 



Conventions 


Definition 


Italics 


The first use of a new or Blue Coat-proprietary term. 


Courier font 


Screen output. For example, command line text, file names, and 
Blue Coat Content Policy Language (CPL). 


Courier Italics 


A command line variable that is to be substituted with a literal 
name or value pertaining to the appropriate facet of your 
network system. 


Courier Boldface 


A Blue Coat literal to be entered as shown. 


Arial Boldface 


Screen elements in the Management Console. 


{ } 


One of the parameters enclosed within the braces must be 
supplied 


[ ] 


An optional parameter or parameters. 


1 


Either the parameter before or after the pipe character can or 
must be selected, but not both. 



Notes and Warnings 

The following is provided for your information and to caution you against actions 
that can result in data loss or personal injury: 



Note: Information to which you should pay attention. 



Important: Critical information that is not related to equipment damage or 

personal injury (for example, data loss). 



WARNING! Used only to inform you of danger of personal injury or physical 
damage to equipment. An example is a warning against electrostatic discharge 
(ESD) when installing equipment. 



About Procedures 

Many of the procedures in this volume begin: 

□ Select Configuration > TabName, if you are working in the Management Console, 
or 

□ From the (config) prompt, if you are working in the command line interface (CLI). 
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Blue Coat assumes that you are logged into the first page of the Management 
Console or entered into configuration mode in the CLI. 



Illustrations 

To save space, screen shots illustrating a procedure often have the bottom portion 
removed, along with the blank space. 



General 

Unique name for this ProxySG Appliance: 



Name : 1 72 . 1 6 . 90 . 44 - Blue Coat 5G200 Series 



Serial number of the ProxySG Appliance: 

Serial number: 





Preview 


Apply 


Revert 


Help 



Figure 1-1 Configuration > General Tab with Bottom Buttons 



□ Preview: Click this button to view the configuration changes before applying 
the configuration to the ProxySG. To modify your changes, click Close and 
return to the the tab whose settings you want to modify. 

□ Apply: Click this button to apply unsaved configuration changes to the 
ProxySG. 

□ Revert: Click this button to revert any unapplied changes to the ProxySG 
configuration. Changes that previously have been applied to the ProxySG are 
not affected. 



□ Help: Click this button to view conceptual and procedural documentation 
about the tab's topic. 



General 

Unique name for this ProxySG Appliance: 



Name: 



172.16.90.44 - Blue Coat SG200 Series 



- Serial number of the ProxySG Appliance: 

Serial number: 



Figure 1-2 Configuration > General Tab with Bottom Buttons Removed 
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Chapter 2: Configuring an Application Delivery Network 



This chapter discusses the Blue Coat implementation of an Application 
Delivery Network (ADN), which optimizes traffic over the enterprise WAN. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ Section A: "ADN Overview" on page 18 

a Section B: "About ADN Deployment, Compression, and Security Behavior" 
on page 24. 

□ Section C: "Basic ADN Setup" on page 30. 

□ Section D: "Transparent and Explicit Connection Deployments" on page 34. 

□ Section E: "Securing the ADN Network" on page 46. 

□ Section F: "ADN Network History, Active Sessions, Byte-Caching Statistics, 
and Health Metrics” on page 54. 

□ Section G: "Advanced Tunnel Optimization" on page 60. 

□ Section H: "Byte-Cache Dictionary Sizing" on page 64. 

□ Section I: "Related CLI Syntax to Configure an ADN Network" on page 70. 

□ Section J: "Policy" on page 72. 
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Section A: ADN Overview 



Visibility is the key to achieving secure application performance while 
maintaining control over users and content. Because proxies terminate 
application traffic, they have a unique and native visibility into the application, 
the user, and the content of the interaction. 

The Blue Coat Application Delivery Network, or ADN, optimizes application 
protocol traffic over the WAN by implementing Blue Coat MACH5 technology. 
MACH5 refers to the following aspects of the Multiprotocol Accelerated Caching 
Hierarchy. 

□ Bandwidth Management — Adds a throttle or modulate option to possible 
actions, which enables organizations to limit or guarantee bandwidth for 
individual (or groups of) applications. 

□ Protocol Optimization — Reduces the effects of latency for common protocols 
that were not initially designed to operate efficiently across WAN links by 
employing object pipelining, local authentication, and DNS caching. 

□ Object Caching — Reduces latency and bandwidth by caching and serving 
application data locally and supporting various pre-placing of commonly- 
requested content. 

□ Byte Caching — Reduces transmitted data at the packet level by replacing large 
chunks of TCP data with smaller tokens that represent that data. 

□ Compression — Reduces transmitted data through various other compression 
technology, such as GZIP, caching compressed and uncompressed objects, and 
HTTP and point-to-point compression. 

The MACH5 optimization techniques complement each other to provide a multi- 
layered approach to application acceleration. As the five layers are governed by 
granular policy, organizations can apply acceleration techniques best suited to 
particular applications. Blue Coat ProxySG appliances located at key points in the 
network allow IT personnel to intercept and control all TCP (and UDP for 
streaming) traffic that is sent over the WAN, such as: 

□ Web (HTTP) 

□ File sharing services (CIFS) 

□ Microsoft Outlook/ Exchange (MAPI) 

□ Secure Web (SSL) 

□ Generic TCP 

□ DNS 

□ Live and on-demand streaming (RTSP, MMS, and streaming over HTTP) 

An ADN defines the physical network that enables application acceleration 
between various corporate offices separated by WAN links with limited 
bandwidth. An ADN consists of ProxySG appliances that are easily integrated 
into the network and provide acceleration and control. An ADN Manager 
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Section A: ADN Overview 

ProxySG located at the corporate location controls and manages other ProxySG 
appliances — called peers — that perform the ADN tasks. These peers are located at 
branch office and corporate data center locations. A branch office peer compresses 
data before sending it to its data center peer, but before accepting traffic from a 
peer, each ProxySG must verify that the peer is a valid member of the ADN. 

The following diagram illustrates a high-level ADN deployment. 




WAN 




When deployed together at various network points, these elements function 
together to form an ADN. 



About the Application Delivery Network Elements 

Am ADN requires a minimum of two ProxySG appliances: one at the core (or 
enterprise data center location) and one at a branch location. Most deployments, 
however, require additional ProxySG appliances to accommodate the volume of 
enterprise users and various locations. 

To create an ADN, you configure ProxySG appliances to serve in various roles in 
the ADN network. Any ProxySG can be configured to be an ADN Manager, 
branch peer or concentrator peer, based on its location in the network and 
connectivity to servers. 

The following table describes the ADN roles of ProxySG appliances deployed at 
various points on the network. 
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Section A: ADN Overview 

Table 2-1 ADN Elements and Network Locations 



ProxySG 


ADN Role 




ADN Manager — Every ADN must have an ADN manager. This device 
performs the following functions: 

• Responsible for the authentication and authorization of peers. 

• In explicit ADN deployments, the ADN Manager Publishes the routing 
table to all ADN peers. 

• In transparent ADN deployments, peers discover each other as packets are 
routed through the ADN (router redirection). 

Although Blue Coat recommends that the ADN Manager not participate as 
an ADN peer, this is an acceptable deployment if you have correctly sized the 
ProxySG appliances. 




Backup ADN Manager — Blue Coat recommends configuring a second 
ProxySG as a backup ADN manager. If a peer in the ADN detects that the 
primary ADN manager is not available (determined by keep alive messages), 
the peer switches to the backup ADN manager. When the primary ADN 
manager resumes responding to the peer, the active routing connection 
returns to the primary ADN manager. 




Concentrator Peer — ProxySG appliances deployed as concentrators reside in 
the data center and connect to a WAN router. Larger enterprises with 
multiple data centers deploy a concentrator in each data center. They can be 
also be deployed in clusters for load balancing and failover. Concentrator 
peers terminate the ADN tunnels, decompress the traffic, and forward the 
uncompressed data to the application server; the application data is then 
compressed and returned over the WAN to the requesting client by way of 
the branch peer. 




Branch Peer — A ProxySG deployed near the gateway of each remote location 
(small or regional offices) that contains a centrally-managed router or where 
there is private IP connectivity through Multi Protocol Label Switching 
(MPLS), satellite, or point-to-point network. To retrieve client file and data 
requests from application servers located in the corporate data center, the 
branch proxy connects to the ADN concentrators — which are advertised by 
the ADN Managers or discovered transparently — in the data centers at the 
corporate location. 

If the branch location has servers, the branch peer also serves as a 
concentrator. 

ADN peers build byte caches and strive to maintain connections with the 
same peers in the network to take advantage of established byte caches. This 
is known as host affinity. 
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Section A: ADN Overview 



Table 2-1 ADN Elements and Network Locations 



ProxySG 


ADN Role 




Client Manager/ProxyClient — For mobile users and remote deployments 
(such as a micro-branch or home office) where users connect directly to the 
Internet through a corporate-controlled VPN, Blue Coat offers the 
ProxyClient solution. When installed on user systems, ProxyClient mimics a 
small ProxySG appliance and provides ADN optimization and Web content 
filtering. A Client Manager is a ProxySG on the ADN that provides 
monitoring and software and configuration updates. Like all peers in the 






1 0 




ADN, the ProxyClient application connects to the ADN Manager and obtains 




the advertised routes from the ADN Manager. 

The Client Manager can be the same ProxySG as the ADN Manager; a 
separate device is not required. 

Note: The ProxyClient component is outside the scope of this document. 
Chapter 12: Accelerating and Controlling Micro-branch and Mobile Connections 
(ProxyClient) in Volume 5: Advanced Netzvorking of the SGOS Configuration 
and Management Suite provides full conceptual and implementation 
information. 



Example 

The following series of diagrams illustrate the principal functionality of an 
explicit ADN (transparent ADN performs the same conceptually). Through 
compression and object caching technologies, the ADN solution reduces WAN 
network traffic and improves the user experience. 



C3B 

Jeff 




ADN PEERS (EXPLICIT ADN) 




c 

Bob 




£ m 

Maya 





The ADN peers advertise their availability to the ADN Manager (denoted by the shield symbol). 
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FIRST CONTENT REQUEST 



Branch 




Core , , 


Cm 






Jeff 








WAN 




CM 

Bob 




C - SS II 






Maya 



User Jeff requests a PowerPoint presentation from a file share named ExampleCorpPresentations 
on a server located at the corporate location. As this application is determined by policy to be 
mission-critical, the connection receives maximum allowed WAN bandwidth. The concentrator 
compresses the data and routes it back to over the WAN and through the branch ProxySG, where 
the content is decompressed, cached, and sent to Jeff’s system. 

Jeff changes the content on two slides and saves the file. When Jeff saves the file, the data is 
transmitted from Jeff's system to the branch ProxySG, which caches the new file, compresses the 
data, and sends only the changed data from the two modified slides over the WAN. The 
Concentrator decompresses the data and sends the updated file to the server. 



SECOND CONTENT REQUEST 


Branch 




Core 






rta° 


Jeff 






i l fl|| 6^ 


WAN 




Full cache hit 




c 




c ■ a ii 

Maya 


Bob 




An hour later, user Bob requests the same Powerpoint presentation. The branch ADN peer serves 
the updated file from the object cache. 
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THIRD AND FOURTH CONTENT REQUESTS 




1: At the corporate campus, Maya retrieves the file from the ExampleCorpPresentations share and 
modifies some content. 



2: Jeff requests the file again. This time, the branch peer registers a partial cache hit, as most of 
object data in the byte cache unchanged. A check to the concentrator peer indicates new object 
data (Maya’s changes). Only the new content is retrieved over the WAN. 



Before deploying and configuring ProxySG appliances in your enterprise to form 
an ADN, you must understand your network topography and select a supported 
deployment type. 
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Section B: About ADN Deployment, Compression, and Security 
Behavior 



This section provides conceptual information regarding various deployments that 
employ WAN optimization. 

Blue Coat recommends that you review this section for a high-level overview of 
the Blue Coat ADN implementation. 

This section contains discussions on: 

□ "Selecting the Correct Deployment" on page 24. 

□ "About ADN Compression" on page 27. 

□ "ADN Security" on page 28. 

Selecting the Correct Deployment 

You must decide if the network should use explicit tunnel connections, 
transparent connections, or a combination of both. Note that ADN peers always 
intercept incoming transparent connections if ADN is enabled. 

□ Transparent: The branch ProxySG connects to the original server destination 
address and port. If an upstream proxy is capable of transparent tunneling, 
the downstream proxy transfers data over the ADN tunnel. The destination 
port is preserved and is not affected by security being enabled. Skip to 
"Transparent Connections" for more information. 

□ Explicit: The branch ProxySG connection is established to the ADN peer 
discovered from the routing lookup table. The connection is established to the 
tunnel listening port by default or, if you are preserving the destination port, 
to the port number the application specifies. Skip to "Explicit Connections" on 
page 26 for more information. 

□ Combination: In some circumstances, some ADN peers can connect 
transparently, while other peers require explicit routing. Skip to "Combination 
of Transparent/Explicit Connections" on page 27. 
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Transparent Connections 

Transparent connections are used when the network is required to see the original 
destination IP addresses and ports. This requires that each peer be configured as 
an ADN peer and deployed in inline mode or virtual inline mode. 



Note: Beyond setting up an ADN peer in an in-line network and configuring 
the ADN peer to point to the ADN manager and backup manager, no 
additional effort is required for transparent connections. If you use explicit 
connections, those connections must be explicitly configured. 



Transparent connections take advantage of ADN tunnels that maintain layer-4 
information from the original application connections. Layer-4 information 
provides an administrator more granular control of the ADN network and allows 
the enforcement of network policy. 

In a transparent connection deployment, connections are not established to a 
particular peer in the ADN, as they are in an explicit deployment. An ADN peer 
can establish connections to its peers automatically in the absence of any ADN 
routing information. 

The reject-inbound per interface setting is honored for transparent tunnel 
interception, while the allow-intercept setting is ignored for transparent tunnel 
interception. 

Internet-bound traffic is automatically accelerated in a transparent deployment if 
a transparent ADN peer is installed at the internet access point and Internet traffic 
is routed correctly. 

Transparent Deployment Load Balancing Scenarios 

In transparent load balancing, routes are not advertised, and configuration of load 
balancing must be done on each peer in the ADN cluster. 

If you are using a transparent deployment, you have two options for load 
balancing. 

□ A dedicated ProxySG appliance as a load balancer; that system makes the 
decision about which peer receives which traffic. 

□ A WCCP router or other external load balancer, where the individual peers in 
the ADN cluster make the informed load balancing decision. 
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Explicit Connections 

Explicit connections are used when maximum network control and granularity is 
needed. 

Blue Coat supports two explicit connections deployments: explicit or explicit but 
preserving the destination port. In the latter case, the destination port used is the 
original destination port from the client's request, such as port 80 for HTTP. The 
destination port is not affected by the connection setting. 

In both explicit deployments, the server subnets that are fronted by each peer 
must be explicitly configured; the server subnets are then advertised to each ADN 
peer. 

To accelerate Internet traffic in an explicit ADN network, set up a specific ADN 
peer as the Internet gateway. Typically, the Internet gateway is an ADN peer close 
to the enterprise's Internet access point. 



Note: If multiple Internet gateways are available, each peer has its own preferred 
Internet gateway to route all Internet subnets. 



When an ADN peer is configured as an Internet gateway, all other ADN peers 

forward the Internet traffic to this peer. The following logic is used by an ADN 

peer to determine if the connection is destined to the Internet: 

□ If the destination address matches an advertised subnet from any of the ADN 
peers, the connection is forwarded to that peer over the ADN tunnel. 

□ If the destination address matches one of the exempted subnets, the 
connection is not forwarded over the ADN tunnel. 

□ If the destination address does not match an advertised subnet or an 
exempted subnet, the connection is forwarded to an ADN peer that is 
designated as an Internet gateway. 

Explicit Deployment Load Balancing Scenarios 

If you use explicit network connections, you have two options when configuring 

load balancing: 

□ A server subnet, where the branch ProxySG makes the decision about the peer 
receiving specific traffic for a destination subnet. This is the easiest and more 
preferred method. For more information, see"Using a Server Subnet" on page 
41. 

□ Am external load balancer, where that system makes the informed decision 
about which peer in the ADN cluster receives specific traffic. For more 
information, see "Using an External Load Balancer" on page 42. 
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Combination of Transparent/Explicit Connections 

In some circumstances, it necessary to use explicit connections in addition to the 
much easier and preferred transparent connection deployment. A transparent 
network that can advertise explicit routing connections is supported. This 
configuration is useful: 

□ When a small branch office is using the ProxyClient, which allows SGOS 
functionality when a ProxySG is not on site. 

□ If some peers are not in an in-line configuration or are incapable of initiating 
transparent connections. 

By default, if an ADN peer is advertising routes, explicit connections are made. If 
no explicit routes are found and there is an upstream proxy in the path capable of 
transparent tunneling, the connection is intercepted. This preference is 
configurable. 

Choosing Which Traffic to Optimize 

When you configure proxy services to manage TCP traffic through the ADN 
network, you can set various attributes that can optimize the traffic for the 
network. A specific attribute, use ADN, allows you to disable ADN for a given 
service. 

For information on using proxy services, including the services available, refer to 
Volume 2: Proxies and Proxy Services. 

About ADN Compression 

ADN compression enables organizations to fully extract every performance 
benefit available when sending data through an ADN tunnel between ProxySG 
appliances. ADN tunnels require that ProxySG appliances on opposite sides of 
the WAN be members of the same ADN network and that the upstream ProxySG 
appliance either be advertising routes to servers to be accessed by appliances on 
the opposite side of the WAN or be deployed inline so that transparent ADN 
tunnels can be used. 

Traffic accelerated between clients and servers is automatically compressed before 
being sent through the ADN tunnel, decreasing bandwidth usage and optimizing 
response time. ADN compression is often used in conjunction with byte caching 
and object caching to achieve optimum results. In the case of byte caching and 
compression, byte caching is first applied to the data and then the resulting data is 
compressed. Both features are enabled by default to optimize ADN directed 
traffic. ADN compression for any arbitrary protocol can also be configured on the 
ProxySG using policy; it can also be controlled separately for both inbound and 
outbound traffic on the WAN. 

For more information on byte caching, see Section H: "Byte-Cache Dictionary 
Sizing" on page 64. 
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ADN Security 

ADN networks can and should be secured. You can limit access by: 

□ Authenticating and authorizing the ADN peers that are allowed on the 
network and prevent unauthorized peers from participating. 

□ Securing ADN connections. 

Authenticating and Authorizing ADN Peers 

By default, authentication and authorization are disabled. 

ADN Peer Authentication 

Secure ADN requires an appliance certificate for each ADN peer, including the 
ADN manager and backup manager for identification. You can provide your own 
device appliance certificates or obtain Blue Coat-issued appliance certificates from 
the Blue Coat CA server. For the most secure environment. Blue Coat-issued 
appliance certificates are recommended. 

To enable secure ADN, you must enable the appliance authentication profile for 
the ADN network to use before configuring any other security parameters. 

In secure ADN mode, full mutual authentication can be supported between the 
ADN manager and the ADN peers and among ADN communicating peers. If 
authorization is enabled on the ADN manager, the peer proxy is authorized 
through an approval mechanism by the ADN manager before joining the 
network. For more information on managing appliance certificates, see 
Chapter 6: "Authenticating a ProxySG". 

ADN Peer Authorization 

Authorization occurs when the ADN manager gives approval for the device to 
join the network. 

If the profile, authentication, and authorization are configured on each peer, and 
the Pending Peers option is enabled on both the ADN manager and the backup 
ADN manager (if one is configured), the following behavior takes place 
automatically: 

□ When an ADN peer comes up, it contacts the ADN manager for routing 
information. 

□ The ADN manager extracts the device ID from the connecting ADN peer's 
appliance certificate and looks for the device ID in its approved list of ADN 
peers. 

• If the device is on the approved list, a request-approved response is sent, 
followed by the route information, and the peer joins the network. 

• If the device is not on the approved list, the ADN manager adds the 
connecting peer's device ID to a pending-peers list and sends a request- 
pending response. After the peer is moved to the Approved list by the 
administrator, a request-approved response is sent, followed by the route 
information, and the peer joins the network. 
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• If the Pending Peers option is not enabled and a peer is not on the approved 
list, the ADN manager sends a request-denied response and closes the 
connection. The connecting peer closes the connection and updates its 
connection status. 

• If a peer is deleted from the approved list, the ADN manager broadcasts a 
reject- peer to all peers to delete this peer and terminate any existing 
ADN connections to it. No new connections are routed through the 
deleted ADN peer. 

For information on configuring authentication and authorization on each ADN 
peer, see "Configuring ADN Security Settings" on page 47. 

Securing ADN Connections 

By default, ADN routing and tunnel connection requests are unauthenticated and 
all ADN protocol messaging and compressed application data are transferred in 
plaintext. For maximum security, you can configure the ADN network to secure 
ADN routing and tunnel connections using standard SSL protocol, which 
provides authentication, message privacy, and message authenticity security 
services, regardless of the application traffic that is being accelerated or tunneled. 

In secure ADN mode, you can specify that the ADN manager and tunnel use 
secure mode to listen for routing and tunnel requests. 

When secure ADN is enabled, any existing plain outbound connections are 
dynamically secured by activating SSL according to the secure-outbound setting. 

For information on optimizing and securing ADN tunnels, see Section E: 
"Securing the ADN Network" on page 46 and Section G: "Advanced Tunnel 
Optimization" on page 60. 
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Section C: Basic ADN Setup 

Basic ADN setup includes: 

□ Configuring each peer in an in-line deployment; if you are configuring an 
explicit deployment, you do not need to configure the network in an in-line 
deployment. 

□ Plugging each peer in. 

□ Enabling the ADN manager and backup manager on each peer, starting with 
the ADN manager and backup manager themselves. 

If you are using a transparent connection deployment without load balancing, 
ADN configuration is complete at this point. 

If you are using an explicit connection deployment, a transparent connection 
deployment with load balancing, or if you are securing the ADN network (highly 
recommended), after finishing this section you must continue with: 

□ "Explicit Load Balancing" on page 41, for explicit deployment. 

□ "Transparent Load Balancing" on page 35, for transparent deployment. 

□ Section E: "Securing the ADN Network" on page 46. 

About the ADN Manager 

The ADN manager keeps track of and advertises the routes of the appliances it 
knows about. The ADN manager must be one of the peers in the ADN 
optimization network. 

A backup ADN manager (optional, but recommended) can also be configured. 
The ADN managers and the registered peers periodically send keep-alive 
messages to each other. If a peer detects the primary ADN manager is not 
responding, the peer automatically fails over to the back-up ADN manager. The 
peer repeatedly attempts to restore its connection with the primary manager. 
After the primary ADN manager is responding to the peer again, the active 
routing connection of this peer switches back to the primary manager. 

If the ADN manager detects a peer is not responding, the ADN manager removes 
the peer from the database and notifies all other peers in the network to do the 
same. 

If both the ADN manager and the backup ADN manager are unavailable, no 
further routing advertisements are broadcast. In this case, routes already known 
by the peers continue to be remembered and used. 

You also can use the ADN manager and backup manager to authorize which 
peers are allowed to advertise or retrieve route information to and from the ADN 
manager, and whether plain connection requests to the ADN manager are 
accepted. 
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ADN Connection Behavior for ADN Managers 

Connections to the ADN manager and backup manager are made at startup and 
kept open as long as ADN is enabled. These connections are referred to as routing 
connections, and are used to advertise configured server subnets and to receive 
routing table updates from the ADN manager. 



Note: Even if you use a transparent tunnel deployment where ADN peers do not 
require routing information, you must configure each ADN peer and register it 
with the ADN manager. If you secure the network (highly recommended), the 
ADN manager is used to authorize ADN peers before they join the network. 



Whenever the ADN manager receives a new advertisement from a peer that is 
joining the network, a route update is sent to all the appliances in the ADN 
optimization network that have already established a routing connection; in 
addition, the current routing table is updated. The ADN manager and backup 
manager can each listen on two ports: one accepting the default plain (unsecured) 
routing connection requests and another accepting secure routing connection 
requests. The plain listener can be shut down if routing connections from all ADN 
peers are secured. 

When ProxySG connects to the primary ADN manager, subnet information is sent 
to the manager, including: 

□ Peer ID: The serial number of the device. This is a globally unique identifier 
for the peer ProxySG that is used as a key to select the dictionary of tokens to 
use. 

□ Data IP Address and Port: The destination IP address and port number that a 
branch proxy should use when establishing an explicit (non preserve-dest- 
port) tunnel connection. 

□ Server Subnet Advertisements: The list of server subnets the ProxySG 
contains are sent to the ADN manager. 
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Configuring the ADN Managers 

The first step in configuring an ADN network is to define the primary ADN 
manager. Blue Coat also recommends deploying a backup ADN manager to 
prevent loss of routing information should the primary ADN manager become 
unavailable for any reason. The ADN manager and backup ADN manager must 
be configured on each peer that is joining the ADN network. 

To enable ADN optimization and define the primary/backup ADN managers: 



Note: Fill in all fields on this pane before clicking Apply. 



1. Select Configuration > ADN > General. 
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2. Select Enable Application Delivery Network. 



3. Primary ADN Manager: Enter the IP address of the primary ADN manager. This 
can be the ProxySG appliance itself or any peer on the ADN optimization 
network. 

4. Backup ADN Manager (Optional but highly recommended): Enter the IP address 
of the backup ADN manager or select the Self radio button if this ProxySG is 
the backup manager. 

5. Manager Ports: The ports are set to 3034 (for plain routing connections) and port 
3036 (for secure routing connections). 

6. Click Reconnect to Managers to connect to the ADN manager and backup ADN 
manager, if one is configured. 



Note: You cannot select this option until you select the primary ADN 
manager and apply the changes. The ADN manager does not exist until the 
changes are applied. 



7. Click Apply. 
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Verification 

□ If the ADN managers connect successfully, the procedure worked. 

□ If the ADN managers did not connect successfully, make sure: 

• Both systems are turned on. 

• Both systems are running the same version of SGOS. 

• Both systems are using the same device profile. 

• The ADN backup manager was approved by the ADN manager to join the 
ADN network (Configuration > ADN > Manager > Pending Peers). 
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Section D: Transparent and Explicit Connection Deployments 

If you are configuring a transparent connection deployment without load 
balancing, remember that ADN peers always intercept incoming transparent 
connections if ADN is enabled. No special configuration is required after basic 
ADN configuration is completed unless you use transparent connection load 
balancing or if you need to configure a combined (explicit and transparent) 
connection network. 

The basic steps for configuring a combined transparent/ explicit deployment or a 
pure explicit deployment are: 

□ Connect the peers in in-line mode or virtual in-line mode only for those peers 
that are using transparent connections. 

□ (Optional) Secure the ADN network: 

• Configure the ADN peers for ADN authentication and authorization for 
maximum security (see "Configuring ADN Security Settings" on page 47). 
The settings on each system should be identical. 

• Configure secure tunnels (see Section G: "Advanced Tunnel Optimization" 
on page 60). 

□ (Optional) Configure the load balancing parameters for each peer to be used 
in load balancing (see "Explicit Load Balancing" on page 41 or "Transparent 
Load Balancing" on page 35). 

To configure transparent connections, including transparent connection load 
balancing, continue with the next section. 

To configure explicit connections, including explicit connection load balancing, 
see "Configuring an Explicit Deployment" on page 38. 

To configure a combined connection deployment, skip to "Configuring a 
Combined (Transparent and Explicit) Deployment" on page 44. 

Configuring a Transparent Deployment 

After you have completed basic ADN configuration, transparent connections are 
made automatically. No further configuration is required, unless you need to 
configure transparent load balancing. 

Transparent Deployment Notes 

□ The first proxy in the chain that supports transparent tunnels and is on the 
same ADN network intercepts ADN transparent tunnel connections. 

□ In transparent load balancing, routes are not advertised, and configuration of 
load balancing must be done on each peer in the ADN cluster. 

□ Transparent load balancing relies on connection forwarding clusters for 
proper operation. All peers in an ADN load balancing group must be part of 
the same connection forwarding cluster. 
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□ In the context of ADN, connection forwarding relates to how to a ProxySG 
handles the first packet of a request. A decision is made on the first packet 
about which ADN peer is best to process that request, and subsequently that 
request is forwarded to that ADN peer from start to finish. If connection 
forwarding is not set up correctly, load balancing fails. For information on 
connection forwarding, see Chapter 4: "TCP Connection Forwarding". 

Transparent Load Balancing 

In transparent load balancing, routes are not advertised, and configuration of load 

balancing must be done on each peer in the ADN cluster. 

If you are using a transparent deployment, you have two options for load 

balancing. 

□ A dedicated ProxySG appliance as a load balancer; that system makes the 
informed decision about which peer receives which traffic. 

□ A WCCP router or other external load balancer, where the individual peers in 
the ADN cluster make the informed load balancing decision. 

Using the ProxySG as a Load Balancer 

When a Blue Coat appliance is used as the external load balancer, it makes the 

decisions about which traffic is directed to which peer. 



Branch 

ProxySG 



ADN Manager 



Legend: 

Black Arrows - ADN Manager Connections 
Red Arrows = Data Packets/Connections 



ProxySG Group 1 
Decision Maker 




ADN Cluster 
Group 1 
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Content 
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) 



ProxySG is Decision Maker 



To configure transparent load balancing with a dedicated Blue Coat appliance as 
the decision maker: 
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□ Deploy the load-balancing ProxySG in-line so that it can transparently 
intercept all traffic. 

□ Enable load balancing on all peers by going to Configuration > ADN > Tunneling > 
Load Balancing, and selecting the Enable Load Balancing checkbox. 

□ (Optional) Configure each box in the cluster with the same load-balancing 
group name. 

□ On the Blue Coat appliance that's acting as the dedicated load balancer, select 

Act as load balancer only through the Configuration > ADN >Tunneling > Load 
Balancing tab. 

□ Put all ADN peers into a connection forwarding cluster. For more information, 
see Chapter 4: "TCP Connection Forwarding" on page 85. 



Note: For load balancing purposes, o special configuration is required for client 
IP address reflection beyond standard configuration. The standard configuration 
is to enable ref lect-client-ip on the branch ProxySG and to set the concentrator 
ProxySG to allow client-ip reflection under ADN tunneling. 



Using a WCCP Router or L4 Switch as a Load Balancer 

Using a WCCP router or L4 switch as a transparent load balancer is similar to 
using a ProxySG as a transparent load balancer, except that WCCP router or L4 
switch must be configured on each system in the cluster. In this scenario, the 
router or switch cannot guarantee ADN peer affinity because the router cannot 
use the peer ID as input for its hash. Because of this, the ADN peers make the 
actual informed routing decisions. 
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To configure transparent load balancing with the peers in the ADN cluster as the 
decision makers: 



□ Enable load balancing on all peers by going to Configuration > ADN > Tunneling > 
Load Balancing, and selecting the Enable Load Balancing checkbox. 

□ (Optional) Set the same group name on all of the peers in the cluster. 

□ Put all ADN peers into a forwarding connection cluster. For more information, 
see Chapter 4: "TCP Connection Forwarding" on page 85. 

□ Configure WCCP settings on all peers. For more information, see Chapter 17: 
"WCCP Settings" on page 411. 

□ Configure WCCP router settings. Review the vendor's documentation for 
information. 
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Note: If client IP address reflection is needed, you must configure WCCP so 
that both traffic from the Branch Appliance to the Origin Content Server and 
traffic from the Origin Content Server to the Branch Appliance is redirected 
through WCCP This requires configuring WCCP on multiple interfaces on 
your router, or configuring "in/ out" rules. If specific ports are desired (rather 
than all ports), you must configure both source-port and destination-port 
rules in two different service groups. 



See Also 

a "WCCP Settings" 

□ Chapter 2, "Services," in Volume 2: Proxies and Proxy Services 

Configuring an Explicit Deployment 

Complete the following steps to configure an explicit deployment: 

□ Configure server subnets on each peer and enable an Internet gateway (see 
"Managing Server Subnets and Enabling an Internet Gateway" ). 

□ (Optional) Preserve the destination port (see "Preserving the Destination Port" 
on page 41). 

□ Configure explicit load balancing (see "Explicit Load Balancing" on page 41) 

Managing Server Subnets and Enabling an Internet Gateway 

The server subnets you create here are advertised by this peer upon joining the 
explicit ADN network. You can also enable the peer as an Internet gateway. In 
addition, subnets not intended to go over ADN tunnels or to be routed to Internet 
gateways can be configured as exempt subnets. 



Note: You can also configure the exempt subnet capability through policy that 
allows you to disable ADN tunnel for specific connections. For more 
information, refer to Volume 10: Content Policy Language Guide. 



To create server subnets for this peer: 

1. Select Configuration > ADN > Routing > Server Subnets. 
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2. Click Add. 

3. In the Add IP/Subnet dialog, enter the following information and click OK 
when you are done: 



• IP / Subnet Prefix field: Enter either an IP address or an IP address and 
subnet in Classless Inter-Domain Routing (CIDR) notation (for example, 

192 . 168 . 0 . 1 / 16 ). 

• Subnet Mask field: Use this field if you entered only an IP address in the 
preceding field (in other words, if you used CIDR notation in the 
preceding field, you do not need to enter a value in this field). 

• To remove excluded subnets, click the subnets to remove and click Remove. 
You must confirm the action. 



• To clear all excluded subnets, requiring traffic from all IP addresses and 
subnets to be tunneled, click Clear all. You must confirm the action. 



4. (Optional) Repeat for additional routes. 

5. Click Apply. 



To enable this peer as an Internet gateway: 

1. Select Configuration > ADN > Routing > Internet Gateway. 
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Server Subnets Internet Gateway Advanced 

2 1> 0 Enable this ProxySG as an Internet Gateway for all subnets except the following: 



Exempt Subnets 
10 . 0 . 0 . 0/8 

172 . 16 . 0 . 0/12 

192 . 168 . 0 . 0/16 



10 . 9 . 59 . 0/24 




4 



| Add | | Remove j | Clear All 

T 

3 

2. Select the Enable this ProxySG as an Internet Gateway for all subnets except the 
following option. 

3. Click Add. 

4. Add the IP/Subnet that must not be routed to Internet gateway(s); click OK. 

Note: Some subnets are on the exempt list by default. Make sure these 
default exempt defaults do not affect the configuration in your environment. 

5. (Optional) Repeat for additional subnets. 

6. Click Apply. 



40 






Chapter 2: Configuring an Application Delivery Network 



Section D: Transparent and Explicit Connection Deployments 

Preserving the Destination Port 

Complete the following procedure. 

To preserve the destination port: 

1. Select Configuration > ADN > Tunneling > Connection. 




2. Select the When a route is available, preserve the destination TCP port number when 
connecting to the ADN peer option. 

Explicit Load Balancing 

Of the two explicit load balancing types, server subnet or external load balancer, 
the server subnet is the preferred and easiest to use. While the server subnets 
must be configured, no additional load balancing settings must be made, and the 
ADN peers explicitly advertise their own IP addresses. 

Using a Server Subnet 

If you use an explicit deployment, or if you just want to load balance traffic 
destined to a specific subnet, configure the subnet as a server subnet on each 
ADN peer within that group. 

To forward the connection destined to the load balanced subnet, each ADN peer 
selects the preferred peer from the list of all peers fronting that subnet. This is 
done by ranking the list of all peers fronting a given subnet from highest to 
lowest. The peer with the highest rank is chosen to route the client traffic for that 
subnet. 



Note: Load balancing is based on a hashing function, meaning that load 
balancing distribution is approximate, tending to be more evenly distributed 
with larger numbers of devices. Also, no allowance is made for equalizing load 
among different-sized hardware in the same ADN cluster. 
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Decision Maker 



Legend: 

Black Arrows = AON Manager Connections 
Red Arrows = Data Packets/Connections 




IP1 



IP2 



IP3 



ADN Cluster 

ProxySG is 
Decision Maker 



Using an External Load Balancer 

If you use explicit deployments, you can rely upon an external load-balancer 
fronting a group of ADN peers. The load balancer is configured to distribute the 
load among the peers that it fronts using client/IP address affinity 

The external load balancer provides more control than the server subnet, but it 
requires more configuration. For example, you must create an external VIP 
address on the Configuration > ADN > Tunneling > Load Balancing tab on each system in 
the ADN cluster; the VIP address is explicitly advertised by the ADN manager. 

Both server subnet and external load balancer use a cluster of ADN peers for load 
balancing. The cluster is formed by ADN peers that are configured to the same 
ADN manager and are advertising the same server subnets. 



42 




Chapter 2: Configuring an Application Delivery Network 



Section D: Transparent and Explicit Connection Deployments 




ADN Cluster 



External Load Balancer 
is Decision Maker 



Whether you are using server subnets or an external load balancer, you must 
configure server subnets. If you are using an external load balancer, you must also 
configure the external load balancer with a VIP address and put the address in the 
Load Balancing tab. Continue with the next procedures to configure explicit load 
balancing. 



Explicit Load Balancing Procedures 

If you want to use either the server subnet load balancing deployment or the 
external load balancing deployment, you must configure server subnets. If you 
are using the external load balancing deployment, you must also configure the 
external load balancer with a VIP address. 



To configure server subnets: 

1. Go to Select Configuration > ADN > Routing. 

2. Click Add. 

3. Add the IP/Subnet route to be advertised by the ADN manager; click OK. 

4. (Optional) Repeat for additional routes. 

For detailed information about configuring server subnets, see "Managing Server 
Subnets and Enabling an Internet Gateway" on page 38. 
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To configure VIP addresses: 

1. Select Configuration > ADN > Tunneling > Load Balancing. 

2. Enter the VIP address of the external load balancer. 

Note: The VIP address is added from the Load Balancing tab of the App 
Delivery Network menu, not the Advanced tab of the Network menu. 

3. Click Apply. 

The address must be entered on each ADN peer in the cluster. 

See Also 

a "Virtual IP Addresses" 

Configuring a Combined (Transparent and Explicit) Deployment 

If you set up a transparent ADN network with no explicit connections, no 
additional configuration is required for transparent tunnel connections to work 
unless you want to configure load balancing. To configure transparent load 
balancing, skip to "Setting Device Security" on page 47. 

If you set up a combined ADN network with both explicit and transparent 
connections, you must: 

□ Configure the explicit routes you need (see "Managing Server Subnets and 
Enabling an Internet Gateway" on page 38). 

□ Configure the routing preference for each ADN peer to tell ADN peers to 
prefer transparent connections (see "To configure the routing preference:" ). 
The default is to always use advertised, explicit, routes. 

□ Set the manager listening mode to Plain read-only mode if ProxyClients are in 
the network (see "To configure ADN manager and tunnel listening mode and 
ports:" on page 50. 

□ Configure transparent or explicit load balancing, if necessary. For more 
information, see "Transparent Load Balancing" on page 35 or "Explicit Load 
Balancing" on page 41. 

To configure the routing preference: 

1. Select Configuration > ADN > Routing > Advanced. 

Server Subnets | Internet Gateway Advanced 

r Routing Preference 

(♦) Tell ADN peers to always use advertised routes 

O Tell ADN peers to prefer transparent connections over advertised routes 

2. Select the Tell ADN peers to prefer transparent connections over advertised routes 

option. 
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See Also 

□ Chapter 2, "Adapters," in Volume 1: Getting Started 

□ Appendix B, "Explicit and Transparent Proxy," in Volume 1: Getting Started 
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Section E: Securing the ADN Network 

Depending on your environment, you might need to secure your ADN network 

to provide the following services: 

□ Host validation: Securing the ADN network allows you to be sure that the 
ADN peers are talking to the right devices and that the peer is authorized to 
join the ADN network. 

□ Privacy: Privacy can be an issue, especially for tunnels that carry application 
data. You can configure the ADN network to secure ADN routing and tunnel 
connections using standard SSL protocol. SSL tunnels provide authentication, 
message privacy, and message authenticity security services, regardless of the 
application traffic that is being accelerated or tunneled. 

□ Message authenticity: Ensure that messages sent over ADN connections are 
not altered. Messages include the route information sent over the routing 
connections and compressed application data sent over the tunnel 
connections. 

Secure ADN implementation includes: 

□ Device authentication, managed through the device authentication profile. 

□ Securing the device, including device authentication profile selection and 
device ID-based peer authorization. 

□ Securing the connections, both inbound and outbound connection security 
control. 

□ Configuring the SSL proxy. 



Note: If you only want secure routing connections to the ADN manager, an 
SSL license is not required. Secure tunnel connections for applications such as 
CIFS, MAPI, TCP Tunnel, HTTP, or HTTPS/SSL, are dependent upon an SSL 
license. 
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Configuring ADN Security Settings 

For information on setting device security, continue with the next section. For 
information on setting connection security, continue with "Securing Connections" 
on page 49. 

Setting Device Security 

For maximum security, configure the ADN network for both device 
authentication and device authorization. Device authentication must be 
configured first. 



Note: If the device being configured for authentication has Internet access, 
acquisition of the ProxySG appliance certificate is automatic. If you use your own 
appliance certificates and profile, or if the affected device does not have Internet 
access, manual device authentication is required. 



For information on configuring device authentication, see Chapter 6: 
"Authenticating a ProxySG". 

After the device authentication has been set up, point the ADN manager and 
ADN backup manager to the profile that is being used for authentication. Then 
enable authorization for maximum security. 



Note: You cannot enable device authorization before configuring the ADN 
manager and backup ADN manager. You can, however, configure the ADN 
manager and backup ADN manager and then, without pressing Apply, enable 
device authorization. Then press Apply to save both tabs. 



To set device security: 

1. Select Configuration > ADN > General > Device Security. 
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General Device Security Connection Security 



2a 

2b 

2c 



2c 



^ SSL Device Profile: | bluecoat-ap pliance-certificate ~v~| 

h> Extracted Device ID: 4605060001 



- Authorization 

[^1 Validate ADN Peer Device IDs 
Primary Manager Device ID: self 
Backup Manager Device ID: 2505060056 




| Retrieve Manager IDs | 


Retrieved Manager IDs 


m 




Primary Manager Device ID: <self> 
Backup Manager Device ID: 2505060056 

[ Accept ] | Reject | 





2. Configure the Device Security options: 

a. SSL Device Profile: From the drop-down list, select the profile that you 
previously associated with the device authentication keyring. Note 
that only devices using the same profile are authenticated. 

b. Extracted Device ID: The device ID that was extracted based on the 
selected profile is automatically displayed. 



Note: The device ID is only used for security. The peer ID is the serial 
number. 



c. To enable authorization, select the Validate ADN Peer Device IDs checkbox. 

• If the primary or backup ADN manager is Self, the device ID is 
automatically displayed. 

• If the primary or backup ADN manager is a different system, click the 
Retrieve Manager IDs button to see the device ID. Click Accept to add the 
Manager device ID to the Authorization field. 



Note: Authorization of devices is not complete until the devices have been 
approved to be part of the network. For more information on approving 
devices, see "ADN Peer Authorization" on page 28. 



3. Click Apply. 

See Also 

"Appliance Certificates and SSL Device Profiles" 
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Securing Connections 

Use the Connection Security tab to set: 

□ Manager and Tunnel Listening Mode 

□ Secure Outbound Connections 

Listening Mode Options 

In secure ADN mode, you can specify that the ADN manager and tunnel use 
secure mode to listen for routing and tunnel requests. By default, ADN routing 
and tunnel connection requests are unauthenticated and all ADN protocol 
messaging and compressed application data are transferred in plain text. 

You must enable the device authentication profile before setting any other 
security parameters. 

After the profile is configured, the following security modes are automatically set: 

□ Secure-outbound: (Secure Proxies) Both outbound routing and secure proxy 
connections are secured. You can also select the radio button to: 

• Not secure ADN connections. 

• Secure only ADN routing connections. 

• Secure all ADN and routing connections. 

Note: The secure-outbound feature is dependent upon an SSL license. 

□ Manager-listening-mode: (Both) Listen for requests on two ports: plain and 
secure. If your deployment requires a different ADN manager listening mode, 
you must explicitly configure it. Other options available are: 

• Secure Only. 

• Plain Only. 

• Plain Read-Only. Use this mode if SG Client is deployed in your ADN 
network. Currently, SG Client does not support secure ADN. 

□ Tunnel-listening-mode: (Both) Listen for requests on two ports: plain and secure. 
Other options are: 

• Secure Only. Do not use this mode if you have SG Client deployed in your 
ADN network. 

• Plain Only. 
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Secure Outbound Connections 

When secure ADN is enabled, any existing plain outbound connections are 

dynamically secured by activating SSL according to the secure-outbound setting. 

Determine which outbound ADN connections are secured by changing the 

secure-outbound parameter. If you select: 

□ None: Neither routing nor tunnel connections are secured. Secure proxy 
connections bypass ADN connections and go directly to the origin content 
sever. 

□ Routing-only: Only routing connections are secured. Secure proxy connections 
bypass ADN connections and go directly to the origin content sever. 

□ Secure Proxies: Routing connections and secure proxy connections are secured. 

□ ALL: All outbound connections are secured. 



Note: Securing all outbound ADN connections should be done only if the 
platform has sufficient capacity to handle the extra overhead. 



The table below describes secure outbound behavior with various applications. 
Table 2-2 Secure Outbound Behavior 



Secure- 

Outbound 

Setting 


Routing 

Connections 


Application Connections 


CIFS 


SSL Proxy 
Intercept Mode 


SSL Proxy 
Tunnel Mode 


None 


Plain Text 


Plain Text 


Bypass ADN 


Bypass ADN 


Routing-only 


Encrypted 


Plain Text 


Bypass ADN 


Bypass ADN 


Secure Proxies 


Encrypted 


Plain Text 


Encrypted 


Encrypted by 
application 


All 


Encrypted 


Encrypted 


Encrypted 


Encrypted by 
application 



To configure ADN manager and tunnel listening mode and ports: 
1. Select Configuration > ADN > General > Connection Security. 
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General j Device Security Connection Security 



2 

3 

4 



- Manager Listening Mode 

O Secure Only <3 Pl^' n Read-Only ® Plain Only O Both 



-o 



-o 



- Tunneling Listening Mode 

0 Secure Only ® Plain Only 0 B °th 

- Secure-Outbound Mode 

® Do not secure ADN connections 
O Secure only ADN routing connections 

O Secure ADN routing connections and tunnel connections made by secure proxies 



0 Secure all ADN routing and tunnel connections 



2. Select a manager listening mode: 



• To change the manager listening mode, go to Configuration > ADN > General > 
Connection Security. The default is Plain-only before the device authentication 
profile is selected. After the device authentication profile is selected, the 
manager listening mode switches to Both by default. 

• To change the manager listening ports, go to Configuration > ADN > General > 
General. The default is plain port 3034 and secure port 3036. 



3. Select a tunnel listening mode: 



• To change the tunnel listening mode, go to Configuration > ADN > General > 
Connection Security. The default is Plain-only before the device authentication 
profile is selected. After the device authentication profile is selected, the 
manager listening mode switches to Both by default. 



• To change tunnel listening ports, go to Configuration > ADN > Tunneling > 
Connection. The default is plain port 3035 and secure port 3037. 



The tunnel listening port is used only if there are explicit tunnel 
connections to this ADN peer using the non-preserve-dest-port mode. 



4. Click Apply. 



Authorizing Devices to Join the Network 

After a peer is configured for authentication (device security) and peer validation 
is enabled on the ADN manager, the peer must be accepted by the ADN manager 
and the backup ADN manager, if configured, before the device is allowed to join 
the network (authorization). 

□ When an ADN peer comes up, it contacts the ADN manager for routing 
information. 

□ If secure-outbound is None on the ADN peer and the ADN manager's listening 
mode is not secure-only, the ADN peer connects to the plain manager 
listening port and immediately joins the ADN network. 
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□ If the ADN peer connects to the secure manager listening port, the ADN 
manager extracts the device ID from connecting ADN peer's appliance 
certificate and looks for the device ID in its approved list of ADN peers. 

• If the device is on the approved list, a request-approved response is sent, 
followed by the route information, and the peer joins the network. 

• If the device is not on the approved list, the ADN manager adds the 
connecting peer's device ID to the pending-peers list and sends a request- 
pending response. After the peer is moved to the Approved list by the 
administrator, a request-approved response is sent, followed by the route 
information, and the peer joins the network. 

• If the Pending Peers option is not enabled and a peer is not on the approved 
list, the ADN manager sends a request-denied response and closes the 
connection. The connecting peer closes the connection and updates its 
connection status. 

• If a peer is deleted from the approved list, the ADN manager broadcasts a 
reject- peer to all peers to delete this peer and terminate any existing 
ADN connections to it. No new connections are routed through the 
deleted ADN peer. To have the denied peer rejoin the ADN network, go to 

ADN > Config > General > Reconnect to Managers. 

To approve a device to join the network: 



Note: Device security must be enabled on all ADN peers you want to join the 
network before you complete this procedure on the ADN manager and 
backup ADN manager. For more information, see "Setting Device Security" 
on page 47. 



1. Select Configuration > ADN > Manager > Approved Peers. 

2. To manage peers that you want to be approved to join the network or that 
have previously been approved to join the network: 

• Add peers to the list by selecting Add; a dialog box displays that allows 
you to enter one or a group of peers by listing one to a line. Click OK when 
through. If the device contacts the ADN manager and is on the approved 
list, a request-approved response is sent, followed by the route 
information, and the peer joins the network. 

• Remove peers by highlighting the peer or peers and selecting Remove. If a 
peer is deleted from the approved list, the ADN manager broadcasts a 
reject- peer to all peers to delete this peer and terminate any existing 
ADN connections to it. No new connections are routed through the 
deleted ADN peer. 
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To manage devices not yet approved to join the network: 

If a peer is configured to contact the ADN manager on startup but has not been 
added to the approved list, the ADN manager adds the peer to the list of pending 
peers if the Allow Pending Peers checkbox is selected. The peer moves from the 
Pending Peers list to the Approved Peers list only through human action. 

1. Select Configuration > ADN > Manager > Pending Peers. 

Approved Peers Pending Peers ' 

0 Allow Pending Peers 




2. Select the Allow Pending Peers option. 

3. To manage pending peers: 

• Highlight a peer and click Accept or Reject; alternatively, you can select or 
reject all peers in the list by clicking Accept All or Reject All. If accepted, the 
peer moves to the Approved list; if not, it is dropped from the Pending Peers 
list. 

• You can also leave peers in the pending list by not selecting them or 
selecting them and clicking Mark Pending. 

4. Click Apply. 

Approved/Pending Notes 

□ Approved lists on the primary and backup ADN managers are not 

automatically kept in sync. You must approve peers on both the primary and 
backup ADN managers. 
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Section F: ADN Network History, Active Sessions, Byte-Caching 
Statistics, and Health Metrics 

After ADN optimization has been enabled and is processing, you can review 
various ADN history and statistics. 

Reviewing ADN History 

Review the ADN history by selecting Statistics > ADN History. 



ADN Statistics 



Peer Dictionary Sizing 



Duration: : Last Hour v 



All peers 



Usage [ Gain 



Peer ID 
3407064185 
106060009 



(megabits per second) 




12:08pm 



12:23pm 



12:38pm 



Peer IP 
10.9.44.114 
10.9.44.126 



Optimized Bytes 
51,248,401 
130,138,700 



10.9.44.126 80.7% 
10.9.44.114 19.2% 




Unoptimized Bytes Optimized Bytes 



Unoptimized Bytes 
2,761,561,685 
11,565,351,876 



Savings 



Help 



You can view either usage statistics or gain statistics (by clicking the Gain tab) and 
either Unoptimized Bytes or Optimized Bytes through the pie charts on the right side. 



The left side of the tab represents optimized and unoptimized bytes trend graphs 
for the selected peer or all peers; hovering the cursor over the graph displays 
statistics in numeric form. For information on tool tips, refer to Volume 9: 
Managing the Blue Coat ProxySG Appliance. 



The right-side pie chart represents optimized and unoptimized bytes for all peers. 
The rows in the table below the graphs represent ADN peers and columns 
representing various aspects of the ADN peers: 



Note: All ProxyClient peers are combined and shown on one row. For more 
information on ProxyClient statistics, see Chapter 12: "Accelerating and 
Controlling Micro-Branch and Mobile User Connections (ProxyClient)" on 
page 173. 
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□ Peer ID: ID of the peer. 

□ Peer IP: IP address of the peer. 

□ Optimized Bytes: Data that has been byte-cached and/ or compressed. 

□ Unoptimized Bytes: Data that is to be byte-cached or compressed and data that 
has been wn-byte-cached or decompressed. 

□ Savings: The percentage of data that did NOT have to be sent over the WAN 
because of object and byte caching, protocol optimization, and compression. 
Moving the cursor over the Savings column value displays tool-tip 
information. 

Selecting any row in the table changes the trend graph at top left and display 
graphs for the selected peer. If you select the last row, which displays totals, the 
trend graph at top left reflects the cumulative data. Changing the duration (using 
the Duration drop-down list) changes the graph accordingly. 

See Also 

□ Chapter 5, "Statistics," in Volume 9: Managing the Blue Coat ProxySG Appliance. 

Reviewing ADN Active Sessions 

You can view active ADN inbound connections through the Statistics > Active 
Sessions > ADN Inbound Connections. Information from the ADN Inbound Connections 

tab can be used for diagnostic purposes. 

Note that these connections are not persistent. When a connection completes, the 
statistics for that connection no longer display. 



Proxied Sessions | Bypassed Connections ADN Inbound Connections 



Filter: None v I Show 



|~1 Limit Display to results 



r ADN Inbound Connections- 




Total displayed connections: 8 
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You can filter on a number of variables, including client, server, or peer IP 
address; server port, or none (shown above). You can also limit the number of 
connections being displayed to the n most recent. 



Note: You must press Show each time you change display options or if you want 
to refresh the page. 



You can terminate an active ADN inbound connection or you can download 

session details. 

□ To terminate an ADN inbound connection, select the session in the list and 
click Terminate Connection. 

□ To download details about all connections as a text file that you can open in a 
spreadsheet program, click Download. Note that all of the connections in the list 
are downloaded. 

Each connection has the following details. 

□ Client: The IP address of the system that is being sent through the ProxySG 
over ADN connections. 

□ Server: The IP address of the server to which you are connecting: CNN, for 
example, or Google. 

□ Peer: The downstream ProxySG or ProxyClient. 

□ Duration: The length of time the connection has been active. 

□ Unopt. Bytes: The amount of data served to/ from the server prior to or 
subsequent to ADN optimization. 

□ Opt. Bytes: The amount of compressed /byte-cached data sent to/ received from 
the downstream ProxySG/ProxyClient. 

□ Savings: A relative percentage of bandwidth savings on the WAN link. 

□ Compression: Whether gzip compression is active in either direction on that 
tunnel. 

□ Byte Caching: Whether byte caching is active in either direction on that tunnel. 

□ Encryption: Whether encryption is active in either direction on that tunnel. 

□ Tunnel Type: One of the following: Explicit, Transparent, or Client. 

See Also 

Chapter 5, "Statistics, in Volume 9: Managing the Blue Coat ProxySG Appliance. 
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Reviewing Byte-Caching Statistics 

To review byte caching statistics, select Statistics > Advanced and select the ADN > 

ADN Statistics link from the list. 

Per-connection, real-time statistics are provided. Each connection has the 

following details: 

□ Client IP address/ port. 

□ Server IP address/ port. 

□ Bytes received from the application: The total bytes received from the client/ 
server/ application proxy. 

□ Bytes sent to the application: The total bytes sent to the client/ server/ 
application proxy. 

□ Bytes received from the peer SG appliance: The bytes received on the ADN 
tunnel connection from the peer at the other end of the WAN link. (This is 
compressed unless byte caching is disabled). 

□ Bytes sent to the peer SG appliance: The bytes sent on the ADN tunnel 
connection to the peer at the other end of the WAN Link. (This is compressed 
unless byte caching is disabled). 

□ Duration: The lifetime of this connection. 

Reviewing ADN Health Metrics 

You can see the state of the ADN network, specifically the ADN peer, by checking 

the Statistics > Health Monitoring> General tab. 

The status can have the values as shown in the following table. The information is 

meant for diagnostic and debugging purposes. 
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Table 2-3 Connectivity to ADN Routing Manager Health Metric 



Status 


Message 


Description 


State 


ADN Health Status 


Connected 


The ADN peer is connected to the 
ADN manager, ready to receive any 
route/peer updates. 

If a backup manager exists, this state 
indicates the peer is connected to both 
Managers. 


OK 




Functionality 

Disabled 


ADN functionality is not enabled. 


OK 




Not operational 


ADN functionality is not operational 
yet — components are starting up or 
shutting down. 


OK 




Connection 

Approved 


The ADN peer has been approved to 
connect to the ADN manager. 


OK 




Connecting 


The ADN peer is in process of 
connecting to ADN manager. 


OK 




Partially 

Connected 


The ADN peer is connected to one 
ADN manager but not the other. 


Warning 




Mismatching 
Approval Status 


The ADN peer is approved by the 
current active ADN manager but is 
rejected by the backup manager. This 
warning only exists if a backup ADN 
manager is configured. 


Warning 




Approval Pending 


The ADN peer is awaiting a decision 
from the active ADN manager for the 
peer's request to join the ADN 
network. 


Warning 




Disconnected 


The ADN peer is not connected to the 
ADN manager and cannot receive 
route/peer information. 

If a backup manager is configured, this 
state indicates the peer is disconnected 
from both manager peers. 


Critical 




Connection 

Denied 


The ADN peer is rejected by the ADN 
managers in the peer's request to join 
the ADN network. 


Critical 
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Table 2-3 Connectivity to ADN Routing Manager Health Metric (Continued) 



Status 


Message 


Description 


State 


ADN Manager Status 


Not an ADN 
manager 


The ADN peer is not an ADN manager. 


OK 




No Approvals 
Pending 


All ADN peers that are requesting to 
join the network are already on the 
approved list. 


OK 




Approvals 

Pending 


ADN peers are requesting to join the 
network. The approvals are made by 
the administrator. 


Warning 
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Section G: Advanced Tunnel Optimization 

Tunnel connections are between the branch and concentrator proxies and are 
made on demand. To reduce connection startup latency, tunnel connections are 
pooled and reused. 

If a route is present, proxies that support ADN optimization use an ADN tunnel 
connection. Data traveling over the tunnel connection is subject to byte caching, 
compression, and encryption, per the defined policies. 

The tunnel connection occurs independently of the ADN optimization options 
chosen for that connection. These options can be configured for specific services 
and can also be modified in policy. 



Note: Encryption options cannot be set through policy. 



Optimization options include byte caching and gzip compression; byte caching 
and gzip compression can be controlled separately for inbound and outbound 
traffic on the WAN. 

By default, ADN routing and tunnel connection requests are unauthenticated and 
all ADN protocol messaging and compressed application data are transferred in 
plaintext. For maximum security, you can configure the ADN network to secure 
ADN routing and tunnel connections using standard SSL protocol, which 
provides authentication, message privacy, and message authenticity security 
services, regardless of the application traffic that is being accelerated or tunneled. 

For information on securing the network, see Section E: "Securing the ADN 
Network" on page 46. 

Setting Advanced Tunneling Parameters 

The tunneling parameters you set determine the behavior when you have special 
environmental needs where the default parameters are not adequate. These 
parameters generally do not need to be changed. Parameters that can be changed 
include: 

□ Connection Settings (see "To configure ADN manager and tunnel listening 
mode and ports:" on page 50). 

□ Network Settings (see "To configure network tunneling settings:" ). 

□ Load Balancing Settings (see "Transparent Load Balancing" on page 35 and 
"Explicit Load Balancing" on page 41). 

□ Proxy Processing Settings (see "To change parameters for proxy processing:" 
on page 63). 

To configure network tunneling settings: 

1. Select Configuration > ADN > Tunneling > Network. 
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Connection Network Load Balancing | Proxy Processing 

- Reflect Client IP 

When an inbound ADN tunnel connection requests Client IP reflection: 

0 Reject the request 

0 Allow the request and reflect the client IP 
0 Allow the request but connect using a local IP 



- TCP Settings 

0 Automatically adjusted: Q Manual override: 



2. Determine the behavior of the concentrator proxy when a branch proxy 
requests client IP reflection. Concentrator client IP reflection configuration 
determines what IP address the concentrator advertises to the origin server as 
the source address — the concentrator's own address (referred to as use local IP) 
or as the proxy's address (referred to as reflect the client IP). 

The option you choose depends mainly on whether or not the concentrator is 
installed inline between the proxy and the origin server, as follows: 

• Reject the request 

Choose this option to reject a proxy's request to reflect the client IP; as a 
result, the connection to the concentrator is rejected. 



Note: The behavior of the ProxyClient is different than the behavior of a 
branch proxy. For the ProxyClient, this option is the same as Allow the request but 
use a local IP. For more information, see "About Reflecting the ProxyClient IP 
Address" on page 194. 



• Allow the request and reflect the client IP 

Choose this option if the concentrator is installed inline between the 
branch proxy and the origin server. This option means the return packets 
will have the branch proxy's IP address as the destination address and 
must be routed back through the same concentrator. 
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• Allow the request but use a local IP 

Choose this option if the concentrator is installed out of line with respect 
to the branch proxy and the origin server and when the option to reflect 
the client IP address results in a failed connection. The next paragraph 
discusses why connections might fail. 

With the option to reflect the client IP enabled, the concentrator opens a 
different connection to the origin server than the one originally opened by 
the branch proxy, so response packets going directly from the origin server 
to the branch proxy will be rejected and the connection will fail. 

3. TCP window size is the number of bytes that can be buffered on a system before 
the sending host must wait for an acknowledgement from the receiving host. 

The TCP window size for ADN optimization tunnel connections is set and 
updated automatically, based on current network conditions and on the 
receiving host's acknowledgement. In most situations, the TCP Settings option 
should be left as Automatically adjusted. 

Only use the Manual override setting if your network environment has 
intervening network equipment that makes the delay appear lower than it 
actually is. These environments are sometimes found on satellite links that 
have high bandwidth and high delay requirements. In this case, the 
automatically adjusted window size would be smaller than optimal. 

The configurable range is between 8 Kb and 4 MB (8192 to 4194304), 
depending on your bandwidth and the round-trip delay. Setting sizes below 
64Kb are not recommended. 



Note: If you know the bandwidth and round-trip delay, you can compute 
the value to use as, roughly, 2 * bandwidth * delay. For example, if the 
bandwidth of the link is 8 Mbits/ sec and the round-trip delay is 0.75 
seconds: 

window =2*8 Mbits/sec * 0.75 sec = 12 Mbits = 1.5 Mbytes 

The setting in this example would be 1500000 bytes. This number goes up 
as either bandwidth or delay increases, and goes down as they decrease. 

You can decrease or increase the window size based on the calculation; 
however, decreasing the window size below 64Kb is not recommended.. 

The window-size setting is a maximum value; the normal TCP/IP 
behaviors adjust downward as necessary. Setting the window size to a 
lower value might result in an artificially low throughput. 



4. Click Apply to commit the changes to the ProxySG. 
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To change parameters for proxy processing: 

1. Select Configuration > ADN > Tunneling > Proxy Processing. 



Connection | Network | Load Balancing Proxy Processing 

- Proxy Processing 

Enable proxy processing for incoming ADN tunnel connections for the following protocol: 

□ http 



2. (Optional) If the concentrator is required to perform HTTP proxy processing 
on requests arriving over an ADN tunnel, select HTTP. For most deployments, 
this is not needed. All proxy processing always happens at the branch proxy; 
generally speaking, the concentrator proxy just compresses and decompresses 
bytes and forwards them to and from the server. If this setting is enabled, 
proxy processing happens at both the branch and concentrator. 

Note: If you enable this setting, do not duplicate any of the policy that 
exists at the branch, since the branch settings still apply. Depending on 
the policy involved, doing the processing twice can cause problems 
(such as doing URL rewrite multiple times) or it might just be 
unnecessary, taking up valuable resources. 



3. Click Apply. 
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Section H: Byte-Cache Dictionary Sizing 

A byte cache dictionary comprises a set of data streams. A data stream can be 
thought of as a binary file containing data extracted from the data sent between 
two peers. The actual dictionary size is determined by the number of data streams 
in the dictionary. 

Dictionary sizing is automatic and generally does not need to be changed. 
However, if a peer's dictionary is too small or too large, you can manually resize 
the dictionary. For more information on manually sizing a peer's dictionary, see 
"Manually Sizing Peers" on page 66. 

Understanding Dictionaries 

Actual dictionary size is determined by the number of data streams in the 
dictionary. For dictionary sizing, the disk is considered full when the amount of 
disk space allocated to byte caching is full. 

Unpopular streams are deleted when the dictionary becomes full. In normal 
operation, the disk is kept nearly full, with data streams being deleted and created 
in nearly the same numbers. 

Understanding Dictionary Sizing 

The actual size of a dictionary is determined by the number of data streams in the 
dictionary. The calculation of the actual size of a dictionary assumes the actual 
size is the product of the number of data streams in the dictionary and the 
maximum size of a data stream, which is 16 megabytes. 

By default, a new peer is allocated 100MB for its dictionary, although it does not 
require that much space at the beginning. The allocated dictionary size is treated 
as a minimum. If resources are available after all dictionaries have been allocated, 
any dictionary can request and get more space. To guarantee a minimum 
dictionary size, the value should be set manually on both peers. (See "To manually 
resize byte cache dictionaries from the Statistics tab:" on page 67.) 

The ProxySG resizes the dictionary automatically for best utilization of the disk 
space, although you can force a re-size if necessary. As dictionary sizing can be an 
expensive operation, it is avoided whenever it is unnecessary. 

The dictionary is resized: 

□ The first time after midnight (UTC) that the dictionary is used. A scheduled 
resizing is skipped if an immediate sizing has been done within the last two 
hours. 

This setting is not configurable. 

□ If you modify the allocation for byte caching by setting the ADN maximum 
disk usage size. This causes a resizing if initialization has been completed. 
Increasing the allocation for byte caching causes a resizing if the byte cache 
status is Insufficient Resources. 
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□ If you manually size a peer (or change the dictionary sizing to AUTO). If there 
is currently enough room to allocate the requested size for the peer, no 
resizing is done. 

□ If a peer either starts or stops using byte caching. If enough disk space is 
available to allocate a dictionary for the peer that is starting to use byte 
caching, no resizing is done; if the byte-cache status is "Insufficient Resources" 
when a peer stops using byte caching, resizing is done. 

The re-sizing allows potentially unused or unutilized dictionaries to be identified, 
freeing resources. 

The allocated size of a dictionary is a minimum size, not a maximum size. 
However, the allocated size is not a guaranteed minimum because it might take 
some time for a dictionary to grow to that size, and because the peer might be 
unable to provide a dictionary that large. 

A peer with no allocated dictionary might still be able to get some data streams 
and do byte caching. In steady state, the disk is nearly full, and as new data 
arrives, streams must be deleted to make room. Only dictionaries whose actual 
size is larger than their allocated size are subject to stream deletion. The smaller 
the dictionary, the less likely it is that a match will be found. If no matches are 
found, gzip compression is the only available optimization. 

Ranking Peers 

A table of peer rankings and dictionary sizes is created and maintained by the 
ProxySG. The highest-ranked peer is listed first. Manually sized peers outrank 
automatically sized peers, independent of their traffic. 

Peer rankings are derived based on the amount of data traffic carried and the 
byte-caching efficiency. 



Note: The rank table can track peers that are using SGOS versions prior to SGOS 
5.3, but these peers cannot dynamically re-size or delete their dictionary. 



If a peer is not using the current SGOS version, the peer is not ranked unless it has 
a manually sized dictionary. 



Note: All manually sized peers using an older version of SGOS have the same 
rank, which is below the lowest ranked manually sized peer using the current 
version of SGOS and above the highest ranked automatically size peer using the 
current version of SGOS; they are displayed in random order. Similarly, all 
automatically sized peers using an older version of SGOS are considered to have 
the same rank; these peers are displayed at the end in random order. 
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The dictionary-sizing algorithm, starting with the highest-ranked peer, does the 
following: 

□ Calculates the recommended size based on traffic history and byte-caching 
efficiency 

□ Allocates this size, if possible. 



Note: If it is not possible to allocate the recommended size, it allocates the 
available disk space if there is at least 100 MB, or else nothing is allocated. No 
lower-ranked peer gets a dictionary. 



Dictionary Sizing Messages 

Peers send messages to each other announcing the allocated memory size; if the 
allocated size is other than zero, it is displayed as the advised size and a 
dictionary is allocated as per the algorithm. 

If the advised size is zero, the peer does not have a dictionary, and no dictionary is 
allocated. If the peer had previously been using byte caching, the disk space 
allocated to that peer's dictionary is eventually freed. 

Ranking New Peers 

When a peer joins the network, it is added to the peer ranking table. How much 
dictionary space the peer is allocated depends: 

□ If no history exists for this peer, the peer is allocated 100MB. 

□ If history does exist for the peer, the peer is allocated a dictionary based on 
that history. 

Manually Sizing Peers 

Under certain circumstances, you might need to manually size a peer that does 
not get enough disk space, or you might have a network where one peer takes a 
disproportionate amount of resources. For example, if there are many peers, it is 
simpler to manually resize the one large dictionary than to manually resize all the 
rest. 

If you determine that the algorithm does not guarantee the right dictionary size 
for a specific peer (either too large or too small), you can control the amount of 
disk space to be set aside for that peer 's dictionary. 



Note: You cannot reduce the space available for byte caching to below the total 
size of all manually sized dictionaries. You also cannot assign a size to a 
dictionary that would cause the total size of all manually sized dictionaries to 
exceed the space available for byte-caching. 
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You can manually resize an ADN byte-caching dictionary in two places in the 
Blue Coat appliance Management Console: From the Statistics > ADN History > Peer 
Dictionary Sizing tab, or from the Configuration > ADN > Byte Caching tab. You might 
find the Statistics tab easier to use, since that tab does not require you to know the 
peer ID. Note, however, that only peers that are known with an established 
dictionary are displayed in the Statistics tab. If a peer is unknown or has no 
existing dictionary, use Configuration > ADN > Byte Caching. 

To manually resize byte cache dictionaries from the Statistics tab, continue with 
the next section. To manually resize byte cache dictionaries from the Configuration 
tab, skip to "To manually resize byte cache dictionaries from the Configuration > 
ADN > Byte Caching tab:" on page 68. 

To manually resize byte cache dictionaries from the Statistics tab: 

1. Select Statistics > ADN History > Peer Dictionary Sizing. 



ADN Statistics Peer Dictionary Sizing 

- Byte Cache Effectiveness 




2. The Peer Dictionary Sizing tab gives you statistics relevant to the byte cache 

dictionary size of all peers on the network. 

• Rank: The ranking of a peer's dictionary. Manually-configured peers have 
a higher rank than dynamically-configured peers. 

• Peer ID: The serial number of the device. 

• Peer IP: The IP address of the device, if it is connected. 

• Byte Cache Score: The score of this peer relative to other peers. Score is 
calculated based on the traffic history and byte-caching efficiency of the 
peer. 

• Peer Traffic (GB/Day): The average amount of pre-byte-cache traffic per day. 

• Fill Rate (GB/Day): The average amount of data put into the dictionary per 
day over the last week. 

• Recommended Diet Size (GB): The dictionary size the Blue Coat appliance 
recommends, based on the peer traffic over the last week. 
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• Actual Diet Size (GB): The actual size of the dictionary. 

3. Highlight the device whose dictionary you want to re-size and click Edit. The 
Edit Peer dialog displays. 

4. To select a dictionary size for the device, select the Manual Re-size radio button 
on the Edit Peer dialog and enter the value you want in megabytes. 

5. Click OK to have the resizing take effect immediately. 

To manually resize byte cache dictionaries from the Configuration > ADN > Byte 
Caching tab: 

1. Select Configuration > ADN > Byte Caching. 

Byte Caching 

Maximum Disk Space to Use for Byte Caching: 50 % 

Max-disk-usage Range should be between 5 and 80 percent of 40 GB 




2. To change the total disk space available for all byte-cache dictionaries, change 
the percentage in the Maximum Disk Space to Use for Byte Caching field. 

The statement Max-disk-usage Range should be between 5 and 80 percent of x GB 

indicates how much of the existing disk can be used for byte caching. 

3. Click New. The Create Manual Dictionary Sizing dialog displays. 




4. Enter the peer ID (serial number) of the device with which you are sharing a 
dictionary. 

5. Enter the new value in megabytes in the Size field or select the Disable Byte 
Caching radio button to disable byte caching for this peer. 
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Note: If you enter an invalid value, an error message displays when you 
click Apply. The error message gives you the maximum accepted value to 
use. Repeat the previous steps to get a valid size. 



Commit Results 



- Results from the 5G after committing changes: 




10.9.59.210 - Blue Coat SG200 Series #(config);; Begin ADN Byte 
Caching Settings 

10.9.59.210 - Blue Coat SG200 Series #(config)adn 

10.9.59.210 - Blue Coat SG200 Series#(config adn)byte-cache 

10.9.59.210 - Blue Coat SG200 Series#(config adn 
byte-cache )peer-size 2505060056 999999999 

% Peer 2505060056 only has room for 16000 MBytes 

10.9.59.210 - Blue Coat SG200 Series#(config adn 
byte-cache )exit 

10.9.59.210 - Blue Coat SG200 Series#(config adn)exit 

10.9.59.210 - Blue Coat SG200 Series #(config);; End ADN Byte 
Caching Settings 





6. Click OK. The peer is added to the manually configured dictionary sizing list 
and is ranked among the other manually sized peers at the top of the 
dictionary byte cache table. 

Dynamic dictionary sizing is re-enabled through highlighting the peer and 
selecting Delete. 
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Section I: Related CLI Syntax to Configure an ADN Network 

□ To enter configuration mode: 

SGOS# (config) adn 
SGOS# (config adn) 



Note: For detailed information on using these commands, refer to Volume 11: 
Command Line Interface Reference . 



□ The following subcommands are available: 



SGOS# (config adn) {enable | disable} 

SGOS# (config adn) exit 
SGOS# (config adn) byte-cache 

SGOS# (config adn byte-cache) max-disk-usage percentage 

SGOS# (config adn byte-cache) peer-size peer-id { sizeinmegabytes I 

auto | none } 

SGOS# (config adn byte-cache) exit 
SGOS# (config adn byte-cache) view 



SGOS# (config adn) load-balancing 



SGOS# (config adn load-balancing) 
SGOS# (config adn load-balancing) 
SGOS# (config adn load-balancing) 
SGOS# (config adn load-balancing) 
SGOS# (config adn load-balancing) 
disable } 

SGOS# (config adn load-balancing) 
SGOS# (config adn load-balancing) 



{enable | disable} 
exit 

external-vip IP_address 
group group_name 

load-balance-only {enable | 

no {external-vip | group} 
view 



SGOS# (config adn) manager 

SGOS# (config adn manager) backup-manager { IPaddress [ID] | self} 
SGOS# (config adn manager) exit 

SGOS# (config adn manager) no {backup-manager | primary-manager} 

SGOS# (config adn manager) port port_number 

SGOS# (config adn manager) primary-manager { IP_address [ID] \ self} 
SGOS# (config adn manager) secure-port secure_port_number 
SGOS# (config adn manager) view [approved-peers | backup-manager-id 
| pending-peers | primary-manager-id] 

SGOS# (config adn manager) approved-peers 

SGOS# (config adn approved-peers) add peer-device-ID 
SGOS# (config adn approved-peers) exit 

SGOS# (config adn approved-peers) remove peer-device-ID 
SGOS# (config adn approved-peers) view 
SGOS# (config adn manager) pending-peers 

SGOS# (config adn pending-peers) {accept | reject} 

SGOS# (config adn pending-peers) {enable | disable} 

SGOS# (config adn pending-peers) exit 

SGOS# (config adn pending-peers) view 

SGOS# (config adn) routing 

SGOS# (config adn routing) exit 

SGOS# (config adn routing) prefer- transparent {enable | disable} 

SGOS# (config adn routing) view 
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SGOS# (config adn routing) advertise-internet-gateway 

SGOS# (config adn routing advertise-internet-gateway) {disable | 
enable } 

SGOS# (config adn routing advertise-internet-gateway) exempt- 
subnet {add { subnet_prefix[/prefix_length] } clear-all | remove 
{ subnet_prefix[ / prefix_length] } | view} 

SGOS# (config adn routing advertise-internet-gateway) exit 
SGOS# (config adn routing advertise-internet-gateway) view 



SGOS# (config adn routing) server- subnets 



SGOS# (config adn routing server-subnets) 
prefix length] 

SGOS# (config adn routing server-subnets) 
SGOS# (config adn routing server-subnets) 
prefix length] 

SGOS# (config adn routing server-subnets) 
SGOS# (config adn routing server-subnets) 



add subnet_prefix [/ 

clear-all 

remove s ubnet_prefix [/ 

exit 

view 



SGOS# (config adn) security 



SGOS# (config adn security) authorization {enable | disable} 
SGOS# (config adn security) exit 

SGOS# (config adn security) manager-listening-mode {plain-only | 
plain-read-only | secure-only | both} 



SGOS# (config adn security) 
SGOS# (config adn security) 

secure-proxies | all } 

SGOS# (config adn security) 
SGOS# (config adn security) 

secure-only | both} 

SGOS# (config adn security) 



no ssl-device-prof ile 
secure-outbound {none 



| routing-only | 



ssl-device-prof ile profile_name 
tunnel -listening-mode {plain- only 



SGOS# (config adn) tunnel 



SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
use-local-ip) 

SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
I window size in bytes} 
SGOS# (config adn tunnel) 



connect- transparent {enable | disable} 
exit 

preserve-dest-port {enable | disable} 
port port_number 

proxy-processing http {enable | disable} 
reflect-client-ip (deny | allow | 

secure-port secure_port_number 

tcp-window-size {auto 

view 
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Section J: Policy 

The following gestures can be used for WAN optimization from either the VPM or 
CPL. 



Note: For more information on using the VPM or CPL to configure policy, refer to 
Volume 6: The Visual Policy Manager and Advanced Policy or Volume 10: Content 
Policy Language Guide. 



□ adn. server (yes | no) (This property overrides all other routing and intercept 
decisions made by ADN based on configuration and routing information.) 

□ adn . server . optimize ( yes | no) 

□ adn . server . optimize . inbound (yes | no) 

□ adn . server . optimize . outbound ( yes | no) 

□ adn . server . optimize . byte-cache ( yes I no) 

□ adn . server . optimize . inbound. byte-cache ( yes | no) 

□ adn . server . optimize . outbound. byte-cache (yes I no) 

□ adn . server . optimize . compress ( yes | no) 

□ adn . server . optimize . inbound. compress ( yes | no) 

□ adn . server . optimize . outbound. compress (yes | no) 

□ adn . server . dscp 



72 



Chapter 2: Configuring an Application Delivery Network 



Section K: Troubleshooting 

Section K: Troubleshooting 

You can troubleshoot your ADN network several ways: 

□ through the test adn diagnostics command 

□ through viewing the ADN configuration 

Each of these tools can provide information about the ADN network and suggest 
reasons for the network failure. 



Using the Test ADN Diagnostics Command 

This command is used to test connectivity from one ProxySG to a server on a 
specified port. This test also can be done with an ADN port to test the success or 
failure of a ProxySG connection to an ADN peer. 

The command provides details of its success or failure. 



Transparent ADN: Success 



Blue Coat SG200 Series# test adn 192.168.0.222 80 

connecting to 192 . 168 . 0 . 222 : 80 ... succeeded! 
Diagnostics 



Route decision 
Route reason 
Route policy 
Connect result 
Remote peer 
Local Addr 
Peer Addr 



Connect Transparently 

ADN transparent due to no explicit route 

Success 

207060009 

192 .168.0. 121 : 64881 

192.168.0. 222:80 



Notes 

□ The remote peer information (device ID and IP address) is provided in a 
successful attempt. 

□ The Remote Peer is the device ID (serial number, in this case) of the remote 
ProxySG the test ADN command found. 

□ The Local Addr is the originating system. 

□ The Peer Addr is the server IP address, a side effect of the test adn command 
and a transparent deployment. Normally, the Peer Addr would be a ProxySG 
IP address. 
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Transparent ADN: Success but no Upstream ADN Connection 



Blue Coat SG200 Series# test adn 192.168.0.222 80 

Connecting to 192 . 168 . 0 . 222 : 80 ... succeeded! 
Diagnostics 



Route decision 
Route reason 
Route policy 
Connect result 
Peer Addr 



Attempted Transparent but went Direct 
ADN transparent due to no explicit route 

Success 

192.168.0.222:80 



Notes 

□ Because no ADN connection existed, the Route decision indicates what 
happened: 

• The test adn command went directly to the server. 

• Success in this case refers to the successful connection to the server but not 
through an ADN connection. 

• Remote peer device ID and local address information were not available. 

Explicit ADN: Success 

Blue Coat SG200 Series# test adn 192.168.0.222 80 

Connecting to 192 . 168 . 0 . 222 : 80 ... succeeded! 

Diagnostics 

Route decision : Connect Explicitly 
Route reason : ADN explicit route found 
Route policy : 

Explicit routes found: 

Peer (207060009) ip#0: 192.168.0.122, ports: 3035,3037 Connect 
result : Success 
Remote peer : 207060009 

Local Addr : 192.168.0.121:53892 

Peer Addr : 192.168.0.122:3035 



Notes 

□ The Remote Peer is the device ID (serial number, in this case) of the remote SG 
the test ADN command found. 

□ The Local Addr is the originating system. 

□ The Peer Addr is the IP address of the remote peer. 
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Explicit ADN: The Upstream Device is not Functioning 



Blue Coat SG200 Series# test adn 192.168.0.222 80 

Connecting to 192 . 168 . 0 . 222 : 80 ... failed with error : 5! 

Diagnostics 



Route decision 
Route reason 
Route policy 
Explicit routes 
Peer (207 
Connect result 
Failure reason 
Network error 
Local Addr 
Peer Addr 



: Connect Explicitly 
: ADN explicit route found 

found: 

060009) ip#0 : 192.168.0.122, 
: Failure 

: Socket internal error 
: Socket error (5) 

: 192.168.0.121:53892 
: 192.168.0.122:3035 



ports : 



3035,3037 



Notes 

□ For an explicit connection, the local IP address is displayed even if a 
connection cannot be established. 

Error Codes 



Table 2-4 Error Codes 



Error Code 


Description 


5 


Networking Input/ output error 


50 


Network is down 


51 


Network is unreachable 


52 


Network dropped connection on reset 


53 


Software caused connection abort 


54 


Connection reset by peer 


55 


No buffer space available 


56 


Socket is already connected 


57 


Socket is not connected 


58 


Can't send after socket shutdown 


59 


Too many references: can't splice 


60 


Operation timed out 


61 


Connection refused 
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Showing the ADN Configuration 

You can view the entire ADN configuration through the show adn CLI command. 
Also, you can use the show adn subcommands to view specific parts of the ADN 
configuration. This section describes the show adn subcommands. 

□ ADN Manager Configuration: The manager configuration shows the primary and 
backup mangers, ports, and where approved devices connect from. 



SGOS# show adn manager 

Primary manager: 

Backup manager: 

Port : 

Secure port: 

Approved device 
2505060056 10 . 25 . 36.48 
Allow pending devices: 
Pending device 



self 

10 . 9 . 59.243 2505060056 

3034 

3036 

Connecting from 
enabled 

Connecting from 



□ Tunnel Configuration: The tunnel configuration displays connection information 
for this device. 



SGOS# show adn tunnel 

Port : 

Secure port: 
proxy-processing http: 
connect-transparent : 
preserve-dest-port : 

TCP window size: 
reflect-client-ip: 



3035 

3037 

disabled 

enabled 

disabled 

auto 

use-local-ip 



□ Load Balance Configuration: The load balance configuration displays the Load 
Balance information for this device. 



SGOS# show adn load-balancing 

Load Balancing Configuration: 

Load-balancing: disabled 

Load-balancing Group: <none> 

Load-balance only mode: disabled; will take traffic 

External VIP: none 



□ Routing Table : The routing table section shows the advertised subnets for this 
device. Note that the routing table is only populated if explicit ADN is used. 



SGOS# show adn routing 

Prefer Transparent: 
Internet Gateway: 
Exempt Server subnet: 
Exempt Server subnet: 
Exempt Server subnet: 
Server subnet: 



disabled 

enabled 

10 . 0 . 0 . 0/8 

172 . 16 . 0 . 0/12 

192 . 168 . 0 . 0/16 
10 . 25 . 36 . 0/24 
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the device. 



SGOS# show adn security 

Ssl-device-profile : 
4605060001) 

Manager-listening mode: 
Tunnel-listening mode: 
Authorization: 
Secure-outbound: 



bluecoat-appliance-certificate (Device- id: 

both 

both 

enabled 

secur e-proxies 



□ Byte Cache Configuration: This section shows the percentage of disk space you 
are allowing this peer to use for byte caching. The recommended range is also 
displayed. For more information on the byte-caching CLI tables that are 
displayed as part of the byte-cache configuration output, continue with the 
next section. 



SGOS# show adn byte-cache 

Byte Cache Configuration: 

Max-disk-usage: 65 

; Max-disk-usage Range should be between 5 and 80 percent of 40 GB 



Byte-Cache Configuration CLI Tables 

As part of the byte-cache configuration CLI output, two tables are displayed: 

□ Global Information 

□ Per-Peer Data 



Viewing Byte-Cache Global Information 

The table has information that affects all caches. 



I Time of | Tot Sizel Total 

I Tot Size 

Current Time (UTC) [ Next Peer Ranking (UTC) | Allocabl | Rec Sizel 
Alloc ' d 



19:50:00 16/04/2008 | 00:00:00 17/04/2008 | 20 GB | 571 MB | 

571 MB 



The table contains the: 

□ current time 

□ time for the next scheduled (daily, at midnight UTC) peer ranking 

□ total allocable disk space (converted from a percent into an actual size in SI 
units — 20GB is 20,000,000,000 bytes) 

□ total recommended size of all dictionaries 

□ total allocated size of all dictionaries 
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Viewing Per-Peer Data 

This table has per-peer data, with one line for each peer (all ProxyClients are 
combined into a single line). 

Peer ID | Traffic | Savings | Adj . | Rec. | Alloc. | Actual | Manual | Flags 

| | | Gzip | Size | Size | Size | Size | 

I | | | | | | | 

6 Clients | 18 MB | 742 KB | 0 B| 30 MB | 30 MB | 8069 MB | 0 B| _ 

Note: One line summarizes all ProxyClients, as shown in the per-peer data table 
above — instead of a peer id, it says "N Clients", and information provided 
includes the total overall client statistics for the traffic, savings, adjusted gzip, 
recommended size, allocated size, actual size, and manual size; the flags column 
displays an unbroken underline. 



Information included is the: 

□ peer id (or the number of ProxyClients) 

□ traffic (total uncompressed data over the last week) 

□ savings (byte-cache savings during the last week) 

□ adjusted gzip data (all the uncompressed data sent or received during the last 
week when byte caching was not being done) 

□ recommended size for this peer's dictionary 

□ allocated size for this peer's dictionary 

□ actual size for this peer's dictionary 

□ manual size for this peer's dictionary 

□ flags 

• N means that the user chose not to do compression when sending data to 
this peer 

• M means that manual sizing is in effect for this dictionary 

• A means that the peer has advertised that it is using a manual size for its 
dictionary 

• P means that the dictionary is peer-limited. The peer has asked for a 
smaller dictionary than allocated. 
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This chapter describes how the ProxySG prevents attacks designed to prevent 
Web services to users. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ About Attack Detection 

□ "Configuring Attack-Detection Mode for the Client" on page 80 

□ "Configuring Attack-Detection Mode for a Server or Server Group" on page 
83 

About Attack Detection 

The SGOS software can reduce the effects of distributed denial of service 
(DDoS) attacks and port scanning, two of the most common virus infections. 

A DDoS attack occurs when a pool of machines that have been infected with a 
DDoS-type of virus attack a specific Web site. As the attack progresses, the 
target host shows decreased responsiveness and often stops responding. 
Legitimate HTTP traffic is unable to proceed because the infected system is 
waiting for a response from the target host. 

Port scanning involves viruses attempting to self-propagate to other machines 
by arbitrarily attempting to connect to other hosts on the Internet. If the 
randomly selected host is unavailable or behind a firewall or does not exist, the 
infected system continues to wait for a response, thus denying legitimate HTTP 
traffic. 

The ProxySG prevents attacks by limiting the number of simultaneous TCP 
connections from each client IP address and either does not respond to 
connection attempts from a client already at this limit or resets the connection. 
It also limits connections to servers known to be overloaded. 

If the ProxySG starts seeing a large number of HTTP errors, and that number 
exceeds the configured error limit, subsequent requests are blocked and the 
proxy returns a warning page. 

If the requests continue despite the warnings, and the rate exceeds the warning 
limit, the client is blocked at the TCP level. 

You can configure attack detection for both clients and servers or server groups, 
such as http: / / www . biuecoat . com. The client attack-detection configuration is 
used to control the behavior of virus-infected machines behind the ProxySG. 
The server attack-detection configuration is used when an administrator knows 
ahead of time that a virus is set to attack a specific host. 

This feature is only available through the CLI. You cannot use the Management 
Console to enable attack detection. 
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Configuring Attack-Detection Mode for the Client 

To enter attack-detection mode for the client: 

From the (config) prompt, enter the following commands: 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) client 

The prompt changes to: 

SGOS# (config client) 

Changing Global Settings 

The following defaults are global settings, used if a client does not have specific 
limits set. They do not need to be changed for each IP address/ subnet if they 
already suit your environment: 

□ client limits enabled: false 

□ client interval: 20 minutes 

□ block-action: drop (for each client) 

□ connection-limit: 100 (for each client) 

□ failure-limit: 50 (for each client) 

□ unblock-time: unlimited 

□ warning-limit: 10 (for each client) 

To change the global defaults: 

Remember that enable/ disable limits and interval affect all clients. The values 
cannot be changed for individual clients. Other limits can be modified on a per- 
client basis. 



Note: If you edit an existing client's limits to a smaller value, the new value only 
applies to new connections to that client. For example, if the old value was 10 
simultaneous connections and the new value is 5, existing connections above 5 are 
not dropped. 



SGOS# (config client) enable-limits | disable-limits 

SGOS# (config client) interval minutes 

SGOS# (config client) block ipaddress [minutes] I unblock ipaddress 
SGOS# (config client) default block-action drop | send-tcp-rst 
SGOS# (config client) default connection-limit 

integer_between_l_and_65535 

SGOS# (config client) default failure-limit integer_between_l_and_500 
SGOS# (config client) default unblock-time minutes_between_10_and_1440 
SGOS# (config client) default warning-limit integer_between_l_and_100 



Table 3-1 Changing Global Defaults 



enable-limits | 




Toggles between true (enabled) and false (disabled). The 


disable -limits 




default is false. This is a global setting and cannot be 






modified for individual clients. 
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Table 3-1 Changing Global Defaults (Continued) 



interval 


integer 


Indicates the amount of time, in multiples of 10 minutes, 
that client activity is monitored. The default is 20. This is a 
global setting and cannot be modified for individual 
clients. 


block | unblock 


ip address 
[minutes] 


Blocks a specific IP address for the number of minutes 
listed. If the optional minutes argument is omitted, the 
client is blocked until explicitly unblocked. Unblock 
releases a specific IP address. 


default block- 
action 


drop | send- 
tcp-rst 


Indicates the behavior when clients are at the maximum 
number of connections or exceed the warning limit: drop 
the connections that are over the limit or send TCP RST for 
connections over the limit. The default is drop. This limit 
can be modified on a per-client basis. 


default 

connect ion- limit 


integer 


Indicates the number of simultaneous connections between 
1 and 65535. The default is 100. This limit can be modified 
on a per-client basis. 


default failure- 
limit 


integer 


Indicates the maximum number of failed requests a client 
is allowed before the proxy starts issuing warnings. Default 
is 50. This limit can be modified on a per-client basis. 


default unblock- 
time 


minutes 


Indicates the amount of time a client is blocked at the 
network level when the client-warning-limit is exceeded. 
Time must be a multiple of 10 minutes, up to a maximum 
of 1440. By default, the client is blocked until explicitly 
unblocked. This limit can be modified on a per-client basis. 


default warning- 
limit 


integer 


Indicates the number of warnings sent to the client before 
the client is blocked at the network level and the 
administrator is notified. The default is 10; the maximum is 
100. This limit can be modified on a per-client basis. 



To create and edit a client IP address: 

Client attack-detection configuration is used to control the behavior of virus- 
infected machines behind the ProxySG. 

1. Verify the system is in the attack-detection client submode. 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) client 
SGOS# (config client) 

2. Create a client. 

SGOS# (config client) create { ipaddress I ip_and_length} 

3. Move to edit client submode. 

SGOS# (config client) edit client_ip_address 

The prompt changes to: 

SGOS# (config client ip address) 

4. Change the client limits as necessary. 
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SGOS# (config client ipaddress) 
SGOS# (config client ipaddress) 
integer between 1 and 65535 
SGOS# (config client ipaddress) 
integer between 1 and 65535 
SGOS# (config client ipaddress) 
SGOS# (config client ipaddress) 
integer between 1 and 65535 



block-action drop | send-tcp-rst 

connection- limit 

failure -limit 

unblock-time minutes 
warning- limit 



Table 3-2 Changing the Client Limits 



block-action 


drop | send-tcp-rst 


Indicates the behavior when the client is at the 
maximum number of connections: drop the connections 
that are over the limit or send TCP RST for the 
connection over the limit. The default is drop. 


connect ion- limit 


integer 


Indicates the number of simultaneous connections 
between 1 and 65535. The default is 100. 


failure- limit 


integer 


Indicates the behavior when the specified client is at the 
maximum number of connections: drop the connections 
that are over the limit or send TCP RST for the 
connection over the limit. The default is 50. 


unblock- time 


minutes 


Indicates the amount of time a client is locked out at the 
network level when the client-warning-limit is exceeded. 
Time must be a multiple of 10 minutes, up to a 
maximum of 1440. By default, the client is blocked until 
explicitly unblocked. 


warning- limit 


integer 


Indicates the number of warnings sent to the client 
before the client is locked out at the network level and 
the administrator is notified. The default is 10; the 
maximum is 100. 



To view the specified client configuration: 

Enter the following command from the edit client submode: 

SGOS# (config client ipaddress) view 
Client limits for 10.25.36.47: 

Client connection limit: 700 

Client failure limit: 50 

Client warning limit: 10 

Blocked client action: Drop 

Client connection unblock time: unlimited 

To view the configuration for all clients: 

1. Exit from the edit client submode: 

SGOS# (config client ipaddress) exit 

2. Use the following syntax to view the client configuration: 

view {<Enter> | blocked | connections | statistics} 
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To view ail settings: 



SGOS# (config client) view <Enter> 

Client limits enabled: true 

Client interval: 20 minutes 



Default client limits: 

Client connection limit: 100 

Client failure limit: 50 

Client warning limit: 10 

Blocked client action: Drop 

Client connection unblock time: unlimited 



Client limits for 10.25.36.47: 

Client connection limit: 700 

Client failure limit: 50 

Client warning limit: 10 

Blocked client action: Drop 

Client connection unblock time: unlimited 



To view the number of simultaneous connections to the ProxySG: 



SGOS# (config 
Client IP 
127 .0.0.1 
10.9.16.112 
10.2.11 .133 



client) view connections 

Connection Count 
1 
1 



1 



To view the number of blocked clients: 



SGOS# (config client) 
Client 
10.11.12. 13 
10.9.44.73 



view blocked 
Unblock time 

2004-07-09 22 : 03 : 06t00 : 00UTC 
Never 



To view client statistics: 



SGOS# (config client) 
Client IP 
10.9.44.72 



view statistics 

Failure Count 
1 



Warning Count 
0 



To disable attack-detection mode for all clients: 

SGOS# (config client) disable-limits 



Configuring Attack- Detection Mode for a Server or Server Group 

Server attack-detection configuration is used when an administrator knows ahead 
of time that a virus is set to attack a specific host. 

You can create, edit, or delete a server. A server must be created before it can be 
edited. You can treat the server as an individual host or you can add other servers, 
creating a server group. All servers in the group have the same attack-detection 
parameters, meaning that if any server in the group gets the maximum number of 
simultaneous requests, all servers in the group are blocked. 

You must create a server group before you can make changes to the configuration. 

To create a server or server group: 

1. At the (config) prompt: 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) server 
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The prompt changes to: 

SGOS# (config server) 

2. Create the first host in a server group, using the fully qualified domain name: 

SGOS# (config server) create hostname 

To edit a server or server group: 

At the (config server) prompt: 

SGOS# (config server) edit hostname 

The prompt changes to (config server hostname). 

SGOS# (config server hostname) {add | remove} hostname 

SGOS# (config server hostname) request-limit integer_from^l_to_65535 

where: 



hostname 




The name of a previously created server or server 
group. When adding a hostname to the group, the 
hostname does not have to be created. The host that 
was added when creating the group cannot be 
removed. 


add | remove 


hostname 


Adds or removes a server from this server group. 


request- limit 


integer 


Indicates the number of simultaneous requests allowed 
from this server or server group. The default is 1000. 



To view the server or server group configuration: 

SGOS# (config server hostname) view 
Server limits for hostname: 

Request limit: 1500 
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This chapter describes how to configure the ProxySG appliance to join peer 
clusters that process requests in asymmetrically routed networks. 

Topics in this Chapter 

The following topics are covered in this chapter: 

□ "About Asymmetric Routing Environments" on page 85 

□ "The TCP Connection Forwarding Solution" on page 86 

□ "Configuring TCP Connection Forwarding" on page 90 

About Asymmetric Routing Environments 

It is common in larger enterprises to have multiple ProxySG appliances 
residing on different network segments; for example, the enterprise receives 
Internet connectivity from more than one ISP If IP spoofing is enabled, 
connection errors can occur because the ProxySG terminates client connections 
and makes a new outbound connection (with the source IP address of the 
client) to the server. The response might not return to the originating ProxySG, 
as illustrated in the following diagram. 
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1: The client makes a request; ProxySG 1 intercepts the connection. 



2: ProxySG 1 terminates the client connection and invokes an outbound connection to the 
server (with the client source IP address). 

3: Based on its internal routing policies, the server believes ISP 2 provides a viable path 
back to the client. 



4: ProxySG 2 intercepts the response with the originating client IP address; however, it 
does not recognize the connection from the client and attempts to reset the connection. 

5: The client connection ultimately times out and the client receives a connection timeout 
error. 



Figure 4-1 Multiple ProxySG appliances in an asymmetric routing environment 



After a connection occurs (either intercepted or bypassed) through any ProxySG 
in the connection forwarding cluster, future packets of any such recorded flow 
that is subject to asymmetric routing are properly handled. The ProxySG also 
recognizes self-originated traffic (from any of the peers of the connection 
forwarding cluster), so any abnormal internal routing loops are also appropriately 
processed. 



The TCP Connection Forwarding Solution 

Enabling TCP Connection Forwarding is a critical component of the following 
solutions: 

□ "About Bidirectional Asymmetric Routing" on page 87. 

□ "About Dynamic Load Balancing" on page 88. 

□ "About ADN Transparent Tunnel Load Balancing" on page 89. 
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About Bidirectional Asymmetric Routing 

To solve the asymmetric routing problem, at least one ProxySG on each network 
segment must be configured to perform the functionality of an L4 switch. These 
selected appliances form a cluster. With this peering relationship, the connection 
responses are able to be routed to the network segment where the originating 
client resides. 

In the 5.1.4.x release, cluster membership is manual; that is, ProxySG appliances 
must be added to a cluster by enabling connection forwarding and adding a list of 
other peers in the cluster. After a peer joins a cluster, it begins sending and 
receiving TCP connections, and notifies the other peers about its connection 
requests. 




1: The client makes a request; ProxySG 1 intercepts the connection. 

2: Because ProxySG 1 and ProxySG 2 are peers in the TCP forwarding cluster, ProxySG 1 
informs ProxySG 2 about the connection request. 

3: ProxySG 1 terminates the client connection and invokes an outbound connection to the 
server (with the client source IP address). 

4: Based on its internal routing policies, the server believes ISP 2 provides a viable path 
back to the client. 

5: ProxySG 2 intercepts the response with the originating client IP address. 

6: ProxySG 2 routes the response back up to the internal network. 

7: ProxySG 1 receives the response and serves the client. 



Figure 4-2 ProxySG appliances share TCP connection information 
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About Dynamic Load Balancing 

In a deployment where one ProxySG receives all of the traffic originating from 
clients and servers from an external routing device and distributes connections to 
other ProxySG appliances, TCP connection forwarding enables all of the 
appliances to share connection information (for each new connection) and the in- 
line ProxySG routes the request back to the originating appliance, thus lightening 
the load on the inline appliance. 




/ t 

/ 



[ProxySG 1 



ProxySG 2 



\ 



ProxySG 3 



WAN 



WAN 





Figure 4-3 A ProxySG appliance serving inline as a load balancer 



In the above network topography, ProxySG SG 1 is deployed inline to receive all 
traffic (by way of a switch) originating from the clients to the servers and servers 
to the clients and serves as a load balancer to the other four ProxySG appliances. 
Appliances 2 through 5 also have independent connectivity to the clients and the 
servers. When all appliances belong to the same peering cluster and have 
connection forwarding enabled, appliance SG 1 knows which of the other 
appliances made a specific connection and routes the response to that appliance. 

In this deployment, a TCP acknowledgement is sent and retransmitted, if 
required, to ensure the information gets there, but each new connection message 
is not explicitly acknowledged. However, if the ProxySG receives packets for a 
connection that is unrecognized, the appliance retains those packets for a short 
time before deciding whether to forward or drop them, which allows time for a 
new connection message from a peer to arrive. 

While adding more peers to a cluster increases the connection synchronization 
traffic, the added processing power all but negates that increase. You can have 
multiple peer clusters, and if you are cognoscente of traffic patterns to and from 
each cluster, you can create an effective cluster strategy. The only limitation is that 
a ProxySG can only be a peer in one cluster. 

The Blue Coat load balancing solution is discussed in greater detail in earlier 
sections of this chapter. 
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About ADN Transparent Tunnel Load Balancing 

TCP connection forwarding is a critical component of the Blue Coat ADN 
transparent tunnel load balancing deployment. Achieving efficient load balancing 
is difficult when ADN transparent tunneling is employed and an external load 
balancer is distributing requests to multiple ProxySG appliances. 

A user-noticeable performance degradation occurs if the router, switch, or load 
balancer sends traffic to a ProxySG that has not been servicing a particular client 
long enough to build up substantial byte caching dictionary, thus the compression 
ratio is low. When the ProxySG appliances connected to the routing device belong 
to the same peer cluster and connection forwarding is enabled, the ADN 
managers on each appliance know which of their peers has the best byte caching 
dictionary with the client and forwards the request. This is illustrated in the 
following diagram. 





Client 3 



1 : Client 3 in a branch office makes another in a series of requests to a server at a 
corporate location. 



2: The load balancer forwards a series of requests to ProxySG 2. 

3: ProxySG 2 has been servicing Client 3 and the ADN Manager has built up a substantial 
compression ratio with ProxySG at the corporate location. 



4: ProxySG 4 contacts the server and sends the response that it receives from the server. 
5: The load balancer sends the next request to ProxySG 3. 

6: ProxySG 3 knows ProxySG 2 has a better compression ratio with this client, and the 
ADN Manager forwards the request over to ProxySG 2. 



Figure 4-4 ADN Transparent Tunnel load balancing with Connection Forwarding enabled 
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Load balancing is based on the IP address of the remote ADN peer. This assures 
that all the traffic from a particular ADN peer to the local ADN cluster always 
goes to a specific local ProxySG, thus eliminating the inefficiency of keeping 
dictionaries for that remote peer on more than one local ProxySG. 

The Blue Coat ADN solution is discussed in greater detail in Chapter 2: 
"Configuring an Application Delivery Network" on page 17. 

TCP Configuration Forwarding Deployment Notes 

When configuring your network for TCP connection forwarding, consider the 
following: 

□ Peers can be added to clusters at any time without affecting the performance 
of the other peers. A ProxySG that joins a peer cluster immediately contacts 
every other peer in the cluster. Likewise, a peer can leave a cluster at anytime. 
This might be a manual drop or a forced drop because of a hardware or 
software failure. If this happens, the other peers in the cluster continue to 
process connection forwarding requests. 

□ Connections between peers are not encrypted and not authenticated. If you do 
not assign the correct local IP address on a ProxySG with multiple IP 
addresses, traffic sent peer to peer might be routed through the Internet, not 
the intranet, exposing your company-sensitive data. 

□ The peering port — the connection between ProxySG connection forwarding 
peers — cannot be configured with bypass services. This means a ProxySG 
cannot be deployed in transparent mode between two ProxySG appliances 
that are peers. 

□ The ProxySG does not enforce a maximum number of appliances a peer 
cluster supports, but currently the deployment is designed to function with 
up to 20 ProxySG appliances. 

□ Because TCP connection forwarding must function across different network 
segments, employing multicasting, even among ProxySG peers on the same 
network, is not supported. 

□ There might be a slight overall performance impact from enabling TCP 
connection forwarding, especially in deployments where traffic is largely 
already being routed to the correct ProxySG. If a substantial amount of traffic 
requires forwarding, the performance hit is equitable to processing the same 
amount of bridging traffic. 

Configuring TCP Connection Forwarding 

As described in the previous concept sections, enabling TCP connection 
forwarding provides one component to a larger deployment solution. After you 
have deployed Blue Coat appliances into the network topography that best fits 
your enterprise requirements, enable TCP connection forwarding on each Blue 
Coat appliance that is to belong to the peering cluster, and add the IP address of 
the other peers. The peer lists on all of the cluster members must be the same, and 
a ProxySG cannot have a different local peer IP address than what is listed in 
another peers list. A peer list can contain only one local IP address. 
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To enable TCP Connection Forwarding: 

1. Select Configuration > Network > Advanced > Connection Forwarding. 



WCCP | VIPs | Failover Connection Forwarding 



4 



0 Enable Connection Forwarding 



2 




Local IP: 10.9.59.246 v 



Port: 3030 



Connection Forwarding Peer IPs 
10.9.59.247 




Peer IPs: 



10.9.59.248 

10.9.S9.249| 




3b 



3a 



-C-| Add I 



Copy To Clipb 



2. From the Local IP drop-down list, select the IP address that is routing traffic to 
this ProxySG. 

Specify the port number (the default is 3030) that the ProxySG uses to 
communicate with all peers, which includes listening and sending out 
connection forwarding cluster control messages to all peers in the group. All 
peers in the group must use the same port number (when connection 
forwarding is enabled, you cannot change the port number). 

3. Add the cluster peers: 

a. Click Add. 

b. In the Peer IPs field, enter the IP addresses of the other peers in the 
cluster that this ProxySG is to communicate connection requests with; 
click OK. 

4. Select Enable Connection Forwarding. 

5. Click Apply. 

This ProxySG joins the peer cluster and immediately begins communicating with 
its peers. 



If you have a larger cluster that contains several peer IP addresses, select all of the 
IP addresses in the Connection Forwarding Peer IPs list and click Copy To Clipboard; 
this action includes the local IP address of the peer you are copying from, and it 
will be correctly added as a remote peer IP address on the next appliance. When 
you configure connection forwarding on the next appliance, click Paste From 



Copying Peers to Another ProxySG in the Cluster 
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Clipboard to paste the list of peers, and click Apply. Whichever peer IP address is the 
new appliance's local IP address is pulled out of the list and used as the local IP 
address on the new appliance. If a local IP address is not found or if more than 
one local IP address is found, the paste fails with an error. 



Removing a Peer 

A network change or other event might require you to remove a peer from the 
cluster. Highlight a peer IP address and click Remove. The peer connection is 
terminated and all connections associated with the peer are removed from the 
local system. 



Note: A CLI command is available that allows you to disable a peer, which 
terminates the communication with other peers, but does not remove the peer 
from the cluster. See the next section. 



Related CLI Syntax to Configure TCP Connection Forwarding 



□ To enter configuration mode: 



SGOS# (config) connection- forwarding 



□ The following subcommands are available: 



SGOS# 

SGOS# 

SGOS# 

SGOS# 

SGOS# 



(config 

(config 

(config 

(config 

(config 



connection 

connection 

connection 

connection 

connection 



forwarding) 

forwarding) 

forwarding) 

forwarding) 

forwarding) 



add ipaddress 
port number 
[enable | disable] 

[clear | remove ip_address] 

[view | exit] 



□ The following configuration and statistics commands are available: 



SGOS# show connection- forwarding configuration 
SGOS# show connection- forwarding statistics 
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Bandwidth management (BWM) allows you to classify, control, and limit the 
amount of bandwidth used by different classes of network traffic flowing into 
or out of the ProxySG appliance. Network resource sharing (or link sharing) is 
accomplished by using a bandwidth-management hierarchy where multiple 
traffic classes share available bandwidth in a controlled manner. 



Note: The ProxySG does not attempt to reserve any bandwidth on the network 
links that it is attached to or otherwise guarantee that the available bandwidth 
on the network can sustain any of the bandwidth limits which have been 
configured on it. The ProxySG can only shape the various traffic flows passing 
through it, and prioritize some flows over others according to its configuration. 



By managing the bandwidth of specified classes of network traffic, you can 

accomplish the following: 

□ Guarantee that certain traffic classes receive a specified minimum amount 
of available bandwidth. 

□ Limit certain traffic classes to a specified maximum amount of bandwidth. 

□ Prioritize certain traffic classes to determine which classes have priority 
over available bandwidth. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ "Bandwidth Management Overview" on page 93 

□ "Configuring Bandwidth Allocation" on page 98 

□ "Bandwidth Management Statistics" on page 102 

□ "Using Policy to Manage Bandwidth" on page 104 

Bandwidth Management Overview 

To manage the bandwidth of different types of traffic that flow into, out of, or 

through the ProxySG, you must do the following: 

□ Determine how many bandwidth classes you need and how to configure 
them to accomplish your bandwidth management goals. This includes 
determining the structure of one or more bandwidth hierarchies if you 
want to use priority levels to manage bandwidth. 

□ Create and configure bandwidth classes accordingly. 

□ Create policy rules using those bandwidth classes to identify and classify 
the traffic in the ProxySG. 
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□ Enable bandwidth management. 

Bandwidth management configuration consists of two areas: 

□ Bandwidth allocation 

This is the process of creating and configuring bandwidth classes and placing 
them into a bandwidth class hierarchy. This process can be done using either 
the Management Console or the CLI. 

□ Flow classification 

This is the process of classifying traffic flows into bandwidth management 
classes using policy rules. Policy rules can classify flows based on any criteria 
testable by policy. You can create policy rules using either the Visual Policy 
Manager (VPM), which is accessible through the Management Console, or by 
composing Content Policy Language (CPL). 



Note: For more information about using VPM to create policy rules, refer to 
Volume 6: The Visual Policy Manager and Advanced Policy. For information about 
composing CPL, refer to Volume 10: Content Policy Language Guide. 



Allocating Bandwidth 

The process of defining bandwidth classes and grouping them into a bandwidth 
class hierarchy is called bandwidth allocation. Bandwidth allocation is based on: 

□ the placement of classes in a hierarchy (the parent/ child relationships). 

□ the priority level of classes in the same hierarchy. 

□ the minimum and/or maximum bandwidth setting of each class. 

For example deployment scenarios, see "Bandwidth Allocation and VPM 
Examples" on page 106. 

Bandwidth Classes 

To define a bandwidth class, you create the class, giving it a name meaningful to 
the purpose for which you are creating it. You can configure the class as you 
create it or edit it later. The available configuration settings are: 

□ Parent: Used to create a bandwidth-management hierarchy. 

□ Minimum Bandwidth: Minimum amount of bandwidth guaranteed for traffic 
in this class. 

□ Maximum Bandwidth: Maximum amount of bandwidth allowed for traffic in 
this class. 

□ Priority: Relative priority level among classes in the same hierarchy. 



94 



Chapter 5: Bandwidth Management 



Parent Class 

A parent class is a class that has children. When you create or configure a 
bandwidth class, you can specify another class to be its parent (the parent class 
must already exist). Both classes are now part of the same bandwidth-class 
hierarchy, and so are subject to the hierarchy rules (see "Class Hierarchy Rules 
and Restrictions" on page 96). 

Minimum Bandwidth 

Setting a minimum for a bandwidth class guarantees that class receives at least 
that amount of bandwidth, if the bandwidth is available. If multiple hierarchies 
are competing for the same available bandwidth, or if the available bandwidth is 
not enough to cover the minimum, bandwidth management is not be able to 
guarantee the minimums defined for each class. 



Note: The ProxySG does not attempt to reserve any bandwidth on the network 
links that it is attached to or otherwise guarantee that the available bandwidth on 
the network can be used to satisfy bandwidth class minimums. The ProxySG can 
only shape the various traffic flows passing through it, and prioritize some flows 
over others according to its configuration. 



Maximum Bandwidth 

Setting a maximum for a bandwidth class puts a limit on how much bandwidth is 
available to that class. It does not matter how much bandwidth is available; a class 
can never receive more bandwidth than its maximum. 

To prevent a bandwidth class from using more than its maximum, the ProxySG 
inserts delays before sending packets associated with that class until the 
bandwidth used is no more than the specified maximum. This results in queues of 
packets (one per class) waiting to be sent. These queues allow the ProxySG to use 
priority settings to determine which packet is sent next. If no maximum 
bandwidth is set, every packet is sent as soon as it arrives, so no queue is built and 
nothing can be prioritized. 

Unlike minimums and priority levels, the maximum-bandwidth setting can 
purposely slow down traffic. Unused bandwidth can go to waste with the 
maximum-bandwidth setting, while the minimum-bandwidth settings and 
priority levels always distributes any unused bandwidth as long as classes 
request it. However, priority levels are not meaningful without a maximum 
somewhere in the hierarchy. If a hierarchy has no maximums, any class in the 
hierarchy can request and receive any amount of bandwidth regardless of its 
priority level. 

Priority 

When sharing excess bandwidth with classes in the same hierarchy, the class with 
the highest priority gets the first opportunity to use excess bandwidth. When the 
high-priority class uses all the bandwidth it needs or is allowed, the next class 
gets to use the bandwidth, if any remains. If two classes in the same hierarchy 
have the same priority, then excess bandwidth is shared in proportion to their 
maximum bandwidth setting. 
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Class Hierarchies 

Bandwidth classes can be grouped together to form a class hierarchy. Creating a 
bandwidth class allows you to allocate a certain portion of the available 
bandwidth to a particular type of traffic. Putting that class into a bandwidth-class 
hierarchy with other bandwidth classes allows you to specify the relationship 
among various bandwidth classes for sharing available (unused) bandwidth. 

The way bandwidth classes are grouped into the bandwidth hierarchy determines 
how they share available bandwidth among themselves. You create a hierarchy so 
that a set of traffic classes can share unused bandwidth. The hierarchy starts with 
a bandwidth class you create to be the top-level parent. Then you can create other 
bandwidth classes to be the children of the parent class, and those children can 
have children of their own. 

To manage the bandwidth for any of these classes, some parent in the hierarchy 
must have a maximum bandwidth setting. The classes below that parent can then 
be configured with minimums and priority levels to determine how unused 
bandwidth is shared among them. If none of the higher level classes have a 
maximum bandwidth value set, then bandwidth flows from the parent to the 
child classes without limit. In that case, minimums and priority levels are 
meaningless, because all classes get all the bandwidth they need at all times. The 
bandwidth, in other words, is not being managed. 

Class Hierarchy Rules and Restrictions 

Certain rules and restrictions must be followed to create a valid BWM class 
hierarchy: 

□ Each traffic flow can only belong to one bandwidth management class. 

You can classify multiple flows into the same bandwidth class, but any given 
flow is always counted as belonging to a single class. If multiple policy rules 
match a single flow and attempt to classify it into multiple bandwidth classes, 
the last classification done by policy applies. 

□ When a flow is classified as belonging to a bandwidth class, all packets 
belonging to that flow are counted against that bandwidth class. 

□ If a minimum bandwidth is configured for a parent class, it must be greater 
than or equal to the sum of the minimum bandwidths of its children. 

□ If a maximum bandwidth is configured for a parent class, it must be greater 
than or equal to the largest maximum bandwidth set on any of its children. It 
must also be greater than the sum of the minimum bandwidths of all of its 
children. 

□ The minimum bandwidth available to traffic directly classified to a parent 
class is equal to its assigned minimum bandwidth minus the minimum 
bandwidths of its children. For example, if a parent class has a minimum 
bandwidth of 600 kbps and each of its two children have minimums of 300 
kbps, the minimum bandwidth available to traffic directly classified into the 
parent class is 0. 
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Relationship among Minimum, Maximum, and Priority Values 

Maximum values can be used to manage bandwidth for classes whether or not 
they are placed into a hierarchy. This is not true for minimums and priorities, 
which can only manage bandwidth for classes that are placed into a hierarchy 
Additionally, a hierarchy must have a maximum configured on a high-level 
parent class for the minimums and priorities to manage bandwidth. 

This is because, without a maximum, bandwidth goes to classes without limit and 
there is no point to setting priorities or minimum guarantees. Bandwidth cannot 
be managed unless a maximum limit is set somewhere in the hierarchy. 

When a hierarchy has a maximum on the top-level parent and minimums, 
maximums and priorities placed on the classes related to that parent, the 
following conditions apply: 

□ If classes in a hierarchy have minimums, the first thing that happens with 
available bandwidth is that all the minimum requests are satisfied. If the 
amount requested is less than the minimum for any class, it receives the entire 
amount, and its priority level does not matter. 

Even though a minimum is considered to be a guaranteed amount of 
bandwidth, satisfying minimums is dependent on the parent being able to 
receive its own maximum, which is not guaranteed. 

□ When all of the classes in a hierarchy have had their minimums satisfied, any 
additional requests for bandwidth must be obtained. When a class requests 
more than its minimum, it must obtain bandwidth from its parent or one of its 
siblings. If, however, a class requests more than its maximum, that request is 
denied — no class with a specified maximum is ever allowed more than that 
amount. 

□ If a class does not have a minimum specified, it must obtain all of the 
bandwidth it requests from its parents or siblings, and it cannot receive any 
bandwidth unless all of the minimums specified in the other classes in its 
hierarchy are satisfied. 

□ Classes obtain bandwidth from their parents or siblings based on their 
priority levels — the highest priority class gets to obtain what it needs first, 
until either its entire requested bandwidth is satisfied or until it reaches its 
maximum. After that, the next highest priority class gets to obtain bandwidth, 
and this continues until either all the classes have obtained what they can or 
until the maximum bandwidth available to the parent has been reached. The 
amount available to the parent can sometimes be less than its maximum, 
because the parent must also participate in obtaining bandwidth in this way 
with its own siblings and/ or parent if it is not a top-level class. 
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Flow Classification 

You can classify flows to BWM classes by writing policy rules that specify the 
bandwidth class that a particular traffic flow belongs to. A typical transaction has 
four traffic flows: 

1. Client inbound — Traffic flowing into the ProxySG from a client (the entity 
sending a request, such as a client at a remote office linked to the appliance). 

2. Server outbound — Traffic flowing out of the ProxySG to a server. 

3. Server inbound — Traffic flowing back into the appliance from a server (the 
entity responding to the request). 

4. Client outbound — Traffic flowing back out of the appliance to a client. 

The figure below shows the traffic flows between a client and server through the 
ProxySG. 



©Client inbound 



© Server Outbound 




Client 



Q Client Outbound 



© Server Inbound 



Server 



Some types of traffic can flow in all four directions. The following example 
describes different scenarios that you might see with an HTTP request. A client 
sends a GET to the ProxySG (client inbound). The appliance then forwards this 
GET to a server (server outbound). The server responds to the ProxySG with the 
appropriate content (server inbound), and then the appliance delivers this content 
to the client (client outbound). 



Policy allows you to configure different classes for each of the four traffic flows. 
See "Using Policy to Manage Bandwidth" on page 104 for information about 
classifying traffic flows with policy. 



Configuring Bandwidth Allocation 

You can use either the Management Console or the CLI to do the following tasks: 

□ Enable or disable bandwidth management. 

□ Create and configure bandwidth classes. 

□ Delete bandwidth classes. 

□ View bandwidth management class configurations. 
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Note: If you plan to manage the bandwidth of streaming media protocols 
(Windows Media, Real Media, or QuickTime), you might want to use the 
streaming features instead of the bandwidth management features described in 
this section. For most circumstances. Blue Coat recommends that you use the 
streaming features to control streaming bandwidth rather than the bandwidth 
management features. For information about the differences between these two 
methods, refer to Volume 3: Web Communication Proxies. 



Enabling Bandwidth Management 

The following procedures explain how to enable or disable bandwidth 
management. 

To enable bandwidth management: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 





Bandwidth Classes 


0 Enable Bandwidth Management 




-Bandwidth Classes 




Bandwidth Class Min(kbps) Max(kbps) 



2. Select Enable Bandwidth Management. 

3. Click Apply. 



Creating, Editing, and Deleting Bandwidth Classes 

The following procedure details how to create bandwidth management class. 

To create a BWM class: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 
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2. Create a new BWM class. 



a. Click New. The Create Bandwidth Class dialog displays. 

b. Class name: Assign a meaningful name for this class. The name can be 
up to 64 characters long; spaces are not allowed. 

c. Parent: (Optional) To assign the class as a child of another parent class 
in the bandwidth class hierarchy, select an existing parent class from 
the drop-down list. 

d. Min. Bandwidth: (Optional) Select Min. Bandwidth and enter a minimum 
bandwidth value in the field (kilobits per second (kbps)). The default 
minimum bandwidth setting is unspecified, meaning the class is not 
guaranteed a minimum amount of bandwidth. 

e. Max. Bandwidth: (Optional) Select Max. Bandwidth and enter a maximum 
bandwidth value in the field. The default maximum bandwidth setting 
is unlimited, meaning the class is not limited to a maximum bandwidth 
value by this setting. 

f. Priority: Select a priority level for this class from the Priority drop-down 
list — 0 is the lowest priority level and 7 is the highest. The default 
priority is 0. 

g. Click OK to close the dialog. 

3. Click Apply. 



rBandwidth Classes- 




Figure 5-1 A child bandwidth management class added to a parent class. 



After you add a child class to a parent class, the parent class is denoted by a folder 
icon. Double-click the folder to view all of the child classes under that parent. 
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To edit a BWM class: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 

2. Highlight the class and click Edit. 

3. Edit the fields as appropriate. 

To delete a BWM class: 

Note: You cannot delete a class that is referenced by another class or by the 
currently installed policy. For instance, you cannot delete a class that is the parent 
of another class or one that is used in an installed policy rule. If you attempt to do 
so, a message displays explaining why this class cannot be deleted. 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 

2. Highlight the class to delete and Delete. 

3. Click Yes to delete the class. 

4. Click Apply. 

Viewing Bandwidth Management Configurations 

You can view the following bandwidth class configurations: 

□ Level in the hierarchy (parent/ child relationships) 

□ Priority level 

□ Maximum bandwidth value 

□ Minimum bandwidth value 

To view BWM configuration: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 

On this tab, you can view a class's minimum, maximum and priority value. 
Top level classes are visible — classes with children have a folder icon on the 
left. 

2. To view the configurations of the child class(es) of a class, double-click the 
folder icon. 

The child classes become visible. A second double-click closes the folder. 

Related CLI Syntax to Configure Bandwidth Management 

□ To enter configuration mode: 

SGOS# (config) bandwidth-management 

□ The following subcommands are available: 

SGOS# (config bandwidth-management) enable | disable 

SGOS# (config bandwidth-management) create | delete bwm_class 

□ To enter edit mode: 

SGOS# (config bandwidth-management) edit bwm_class 
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□ The following subcommands are available: 

SGOS# (config bw-class bwm_class) min-bandwidth minimum_in_kbps 
SGOS# (config bw-class bwm_class) max-bandwidth maximum_in_kbps 

SGOS# (config bw-class bwm_class) priority value_from_0_to_7 
bandwidth-management bwm^class) no {min-bandwidth | max-bandwidth} 

SGOS# (config bandwidth-management bwm__class) parent parent^class^name 

-or- 

SGOS# (config bandwidth-management bwm__class) no parent 
SGOS# (config bandwidth-management bwm__class ) view 

Bandwidth Management Statistics 

The bandwidth management statistics tabs (Current Class Statistics and Total 
Class Statistics) display the current packet rate and total number of packets 
served, the current bandwidth rate, and the total number of bytes served and 
packets dropped. 

Current Class Statistics Tab 

The Current Class Statistics tab displays the following information for each 
bandwidth class: 

□ Current Packet Rate: current packets-per-second (pps) value. 

□ Current Bandwidth: current bandwidth in kilobits per second (Kbps). 

To view current bandwidth management class statistics: 

1. Select Statistics > Bandwidth Management > Current Class Statistics. 

The high level bandwidth classes and their statistics are visible. 



Current Class Statistics Total Class Statistics 



rBandwidth Classes- 



Bandwidth Class 


| Current Packet Rate(pps) | 


Current Bandwidth(kbps) | 


• bridging 


0 


0 


• ftp 


0 


0 


• http 


0 


0 


# im 


0 


0 


I streaming 


0 


0 


• P2p 


0 


0 


• service-info 


0 


0 


• socks 


0 


0 


• tcp-tunnel 


0 


0 



Help 



2. To view the statistics of child bandwidth classes, double-click the folder icon 
of the parent class. 



The child classes become visible. A second double-click closes the folder. 
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Total Class Statistics Tab 

The Total Class Statistics tab displays the following information for each bandwidth 
class: 

□ Packets: the total number of packets served. 

□ Bytes: the total number of bytes served. 

□ Drops: the total number of packets dropped. 

To view total bandwidth management class statistics: 

1. Select Statistics > Bandwidth Management > Total Class Statistics. 

The high level bandwidth classes and their statistics are visible. 



Current Class Statistics Total Class Statistics 

rBandwidth Classes 




Help 



2. To view the statistics of child bandwidth classes, double-click the folder icon 
of the parent class. A second double-click closes the folder. 



Bandwidth Management Statistics in the CLI 

To view bandwidth management statistics: 

1. To view all bandwidth management statistics, enter the following commands 
at the prompt: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) view statistics 

2. To view the BWM statistics for a specific class, enter the following command 
at the (config) command prompt: 

SGOS# (config bandwidth-management) view statistics bwm_class 
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Example 



SGOS# (config bandwidth-management) view statistics http 


Class Name: 


http 


Parent : 


<none> 


Minimum Bandwidth: 


unspecified 


Maximum Bandwidth: 


unlimited 


Priority: 


0 


Total Bytes: 


0 bytes 


Total Packets: 


0 pkts 


Dropped Packets: 


0 pkts 


Current Bandwidth: 


0 kbps 


Current Packet Rate: 


0 pps 


Queue Length: 


0 bytes 



Parent 


The class name of the parent of this class. 


Minimum Bandwidth 


The maximum bandwidth setting for this class. 


Maximum Bandwidth 


The minimum bandwidth setting for this class. 


Priority 


The priority level for this class. 


Total Bytes 


The total number of bytes served. 


Total Packets 


The total number of packets served. 


Dropped Packets 


Total number of packets dropped (packets in the queue 
that are dropped because the queue length is reached). 


Current Bandwidth 


Current bandwidth value (in kilobits per second). 


Current Packet Rate 


Current packets-per-second value. 


Queue Length 


Maximum length allowed for the queue of packets that 
lack available bandwidth but are waiting for bandwidth to 
become available. 



To clear bandwidth management statistics: 

1. To clear bandwidth management statistics for all bandwidth management 
classes, enter the following command at the prompt: 

SGOS# clear-statistics bandwidth-management 

2. To clear bandwidth management statistics for a particular class, enter the 
following command at the prompt: 

SGOS# clear-statistics bandwidth-management class bandwidth_class_name 

Using Policy to Manage Bandwidth 

After creating and configuring bandwidth management classes, create policy 
rules to classify traffic flows using those classes. Each policy rule can only apply 
to one of four traffic flow types: 

□ Client inbound 

□ Client outbound 

□ Server inbound 
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□ Server outbound 

You can use the same bandwidth management classes in different policy rules; 
one class can manage bandwidth for several types of flows based on different 
criteria. However, any given flow is always be counted as belonging to a single 
class. If multiple policy rules match a flow and try to classify it into multiple 
bandwidth classes, the last classification done by policy applies. 

To manage the bandwidth classes you have created, you can either compose CPL 
(see "CPL Support for Bandwidth Management" on page 105 below) or you can 
use VPM (see "VPM Support for Bandwidth Management" on page 105). To see 
examples of policy using these methods, see "Bandwidth Allocation and VPM 
Examples” on page 106 or "Policy Examples: CPL" on page 113. 

CPL Support for Bandwidth Management 

You must use policy to classify traffic flows to different bandwidth classes. Refer 
to Volume 10: Content Policy Language Guide for more information about writing 
and managing policy. 

CPL Triggers 

You can use all of the CPL triggers for BWM classification (refer to Volume 10: 
Content Policy Language Guide for information about using CPL triggers). Basing a 
bandwidth decision on a trigger means that the decision does not take effect until 
after the information needed to make that decision becomes available. For 
example, if you set the CPL to trigger on the MIME type of the HTTP response, 
then the HTTP headers must be retrieved from the OCS before a classification can 
occur. The decision to retrieve those headers occurs too late to count any of the 
request bytes from the client or the bytes in the HTTP response headers. However, 
the decision affects the bytes in the body of the HTTP response and any bytes sent 
back to the client. 



Supported CPL 

Bandwidth class can be set with policy on each of these four traffic flows: 

□ limit_bandwidth . client . inbound (none | bwm_class ) 

□ limit_bandwidth . client . outbound (none | bwm_class ) 

□ limit_bandwidth. server . inbound (none | bwm_class ) 

□ limit_bandwidth . server . outbound (none | bwm__class ) 

If you set policy to none, the traffic is unclassified and is not to be bandwidth- 
managed. 



VPM Support for Bandwidth Management 

You can manage bandwidth using VPM in the Action column of four policy layers: 
Web Access, DNS Access, Web Content, and Forwarding Layers. For more 
information about using VPM to manage bandwidth, refer to Volume 6: The Visual 
Policy Manager and Advanced Policy. For examples of bandwidth management 
scenarios using VPM, see "Bandwidth Allocation and VPM Examples" below. 
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Bandwidth Allocation and VPM Examples 

This section illustrates how to use the VPM to allocate bandwidth, arrange 
hierarchies, and create policy. It describes an example deployment scenario and 
the tasks an administrator must accomplish to manage the bandwidth for this 
deployment. For specific instructions about allocating bandwidth, see 
"Configuring Bandwidth Allocation" on page 98. For examples of CPL bandwidth 
management tasks, see "Policy Examples: CPL" on page 113. 

Task One: Bandwidth Allocation 

The administrator is responsible for managing the bandwidth of three branch 
offices. He was told to ensure that each office uses no more than half of its total 
link bandwidth for Web and FTP traffic. The total link bandwidth of each office is 
as follows: 

□ Office A: 1.5 Mb 

□ Office B: 1 Mb 

□ Office C: 2 Mb 

He creates one bandwidth class for each of the three offices and configures the 
maximum bandwidth to an amount equal to half of the total link bandwidth of 
each, as shown below. He also creates policy rules for each class, as described 
below in "Task One: VPM". 



f Office A ] 


f Office B ] 


f Office C \ 


\ Max-BW=750 J 


V Max-BW=500 J 


l Max-BW=1000 j 



Each of the classes above has a maximum set at an amount equal to half of the 
total link bandwidth for each office. A hierarchy does not exist in this scenario. 



Task One: VPM 

The administrator has created one bandwidth class for each office, setting a 
maximum bandwidth on each one equal to the half of the total link bandwidth of 
each. Now he must create policy rules to classify the traffic flows. 



106 



Chapter 5: Bandwidth Management 



FTP/HTTP Limitations 



Destination 

ll£ 



Service 

Any 



Time 

lAnv 



Action Track 

fa Denv iNone 







Add 



Close 



Help 



The administrator launches the VPM and creates a new Web Access Layer, 
naming it FTP/HTTP Limitations. He selects the Client IP Address/Subnet object in the 
Source column, filling in the IP address and mask of the subnet used by Office_A. 




Virus Detected 



He selects a Combined Service Object in the Service column, naming it FTP/HTTP and 

adding a Client Protocol for FTP and for HTTP 




107 






Volume 5: Advanced Networking 




He adds both protocols to the At least one of these objects field. 




In the Action column, he selects Manage Bandwidth, naming it Office_A and setting it 
to manage the bandwidth of Office_A on the Client side in the Outbound direction. 

He adds two more similar rules for the other two offices. He is able to reuse the 
same Combined Service Object in the Service column, but must add new objects 
specific to each office in the Source and Action columns. The order of the rules does 
not matter here, because each office, and thus each rule, is distinct because of its 
IP address/ subnet mask configuration. 

Task Two: Bandwidth Allocation 

A few days later, the administrator gets a visit from the CEO of his company. She 
wants him to fix it so that she can visit any of the branch offices without having 
her own Web and FTP access slowed down unnecessarily. 

The administrator creates two more classes for each office: one for the CEO and 
another for everyone else (employees). He sets the parent class of each new class 
to the appropriate class that he created in Task One. For example, he creates 
Emp_A and CEO_A and sets their parent class to Office_A. He also sets a priority 
level for each class: 0 (the lowest) for employees and 1 for the CEO. He then uses 
VPM to create additional policy rules for the new classes (see "Task Two: VPM" on 
page 109). This figure shows the hierarchical relationship among all of the classes. 
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The administrator now has three separate hierarchies. In each one, bandwidth is 
limited by the configuration of the parent class, and the two child classes are 
prioritized to determine how they share any unused bandwidth. Because no 
minimums have been set, the highest priority class has the first opportunity to use 
all of the available bandwidth; whatever is left then goes to the next priority class. 

Priority levels are only effective among the classes in the same hierarchy. This 
means that the priority levels for the Office_A hierarchy do not affect the classes in 
the Office_B or Office_C hierarchies. 

Task Two: VPM 

Because the CEO wants to prioritize FTP and HTTP access among employees and 
herself, the administrator must create additional bandwidth classes (as described 
above in "Task Two: Bandwidth Allocation") and write policy rules to classify the 
traffic for the new classes. 



Service 



Time 



Action 



Track 



Comment 




He first edits each of the three VPM rules for the three offices. He edits each the 
Manage Bandwidth objects, changing the name of the objects to Emp_A, Emp_B, 
and Emp_C and changes the bandwidth class to the corresponding employee class. 
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Next, he creates three more rules for the CEO, moving them above the first three 
rules. For the CEO rules, he selects the same combined FTP/HTTP object in the 
Service column; in the Action column, he selects a Manage Bandwidth object 
configured for client side/ outbound, as before, but this time, he names the objects 
CEO_A, CEO_B, and CEO_C and selects the corresponding CEO bandwidth class. In 
the Source column, he creates a Combined Source Object, naming it for the CEO. He 
combines the Client IP/subnet object already created for each office with a User 
object that he creates for the CEO. 

The administrator places all three CEO rules above the employee rules, because 
the ProxySG looks for the first rule that matches a given situation and ignores the 
remaining rules. If he had placed the CEO rules below the employee rules, the 
appliance would never get to the CEO rules because the CEO's Web surfing client 
IP address matches both the CEO rules and the employee rules, and the ProxySG 
would stop looking after the first match. With the CEO rules placed first, the 
appliance applies the CEO rules to the CEO's Web surfing, and an employee's 
Web surfing does not trigger the CEO rules and instead skips ahead to the 
appropriate employee rule. 

Task Three: Bandwidth Allocation 

It soon becomes apparent that CEO visits are causing problems for the branch 
offices. At times, she uses all of the available bandwidth, resulting in decreased 
productivity throughout the office she visits. Also, management has complained 
that they have been given the same priority for FTP and HTTP traffic as regular 
employees, and they are requesting that they be given priority over employees for 
this type of traffic. 

First, the administrator creates two new classes for each office. In this example, we 
look at the classes and configurations for the first office only. He creates a class 
called Staff_A and sets a minimum bandwidth of 500 kbps on it. He also creates a 
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class called MgmtA, setting the priority to 1 and the parent to Staff_A. He edits the 
class Emp_A, setting the parent to Staff_A. Finally, he edits the class CEO_A, 
changing the priority to 2. The resulting hierarchy is illustrated below. To see what 
the administrator did to the policy rules, see "Task Three: VPM" on page 111. 




In the example illustrated above, employees and management combined are 
guaranteed a total of 500 kbps. The CEO's priority level has no effect until that 
minimum is satisfied. This means that the CEO can only use 250 kbps of 
bandwidth if the rest of the staff are using a total of 500 kbps. It also means that 
the CEO can use 750 kbps if no one else is using bandwidth at the time. In fact, 
any of the classes can use 750 kbps if the other classes use none. 

Priority levels kick in after all of the minimums are satisfied. In this example, if 
the staff requests more than 500 kbps, they can only receive it if the CEO is using 
less than 250 kbps. Now notice that the minimum setting for the staff is set on the 
parent class, Staff_A, and not on the child classes, Emp_A or Mgmt_A. This means 
that the two child classes, representing employees and management, share a 
minimum of 500 kbps. But they share it based on their priority levels. This means 
that management has priority over employees. The employees are only 
guaranteed a minimum if management is using less than 500 kbps. 

Task Three: VPM 

The administrator has added additional classes for each office and edited the 
existing employee classes, as described above in "Task Three: Bandwidth 
Allocation" on page 110. One of the new classes he added for each office is a 
parent class that does not have traffic classified to it; it was created to provide a 
minimum amount of bandwidth to its child classes. Not every class in the 
hierarchy has to have a traffic flow. This means that he needs to add just three 
more rules for the three new management classes. For the management rules, he 
selects the same combined FTP/HTTP object in the Service column; in the Action 
column, he selects a Manage Bandwidth object configured for client side/ outbound 
with the bandwidth class one of the management classes (Mgmt_A, Mgmt_B, or 
Mgmt_C). In the Source column, he creates a Combined Source Object containing the 
subnet object for the office and the Group object for management. 
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The management rules must go above the employee rules, although it does not 
matter where they are placed in relation to the CEO rules. This would not be true 
if the CEO was part of the same group as management, however. If that were true, 
the CEO rules would still need to go on top. 

Task Four: Bandwidth Allocation 

The administrator decided later that he needed to guarantee employees some 
bandwidth. He configures a minimum for the class Emp_A, as illustrated below. 




He decides to leave the minimum on the parent class Staff_A and not to set a 
minimum for the class Mgmt_A. This is okay, because the minimum of the parent 
class is available to its children if the parent class does not use all of it, and the 
only way that the CEO can get more than 250 kbps is if the employees and 
management combined use less than 500. 

This last change does not require additional changes to policy; the administrator 
has added a minimum to a class that he has already classified for traffic using 
policy. 

In the above scenario, the class called Staff_A does not have traffic configured for 
it — it was created to guarantee bandwidth minimums for its child classes. 
However, if it were configured for traffic, it would have a practical minimum of 
300 kbps. The practical minimum of a parent class is equal to its assigned 
minimum bandwidth minus the minimums of its children. In that case, if the 
parent class Staff_A used 300 kbps and the child class Emp_A used 200 kbps, the 
child class Mgmt_A would not receive any bandwidth unless the class CEO_A was 
using less than 250 kbps. Under those circumstances, the administrator probably 
also needs to create a minimum for management. 

Task Five: Bandwidth Allocation 

The CEO makes another request, this time for the main office, the one the 
administrator himself works from. This office uses the content filtering feature of 
the ProxySG to control the types of Web sites that employees are allowed to view. 
Although the office uses content filtering, access to sports sites is not restricted 
because the CEO is a big fan. 
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The administrator creates a bandwidth management class called Sports with a 
maximum bandwidth of 500 kbps and launches VPM to create policy for this class 
as described below. 

Task Five: VPM 

To classify traffic for the Sports class, the administrator opens VPM, creates a Web 
Access Layer, and sets the Destination column to the Category object that includes 
sports viewing (content filtering is already set up in VPM). He sets the Action 
column to the Manage Bandwidth object, selecting Server side/inbound and the Sports 
bandwidth class he created. After installing the policy and verifying that 
bandwidth management is enabled, he is finished. 

Policy Examples: CPL 

The examples below are complete in themselves. The administrator uses CLI to 
create and configure bandwidth management classes and writes CPL to classify 
traffic flow for these classes. These examples do not make use of a bandwidth 
class hierarchy. For examples of hierarchies, see "Bandwidth Allocation and VPM 
Examples" on page 106. 

Example One: CPL 

In this example, the administrator of a college is asked to prevent college students 
from downloading MP3 files during peak hours, while still allowing the music 
department to download MP3 files at any time. The CPL triggers used are 
authentication and/ or source subnet and MIME type. The action taken is to limit 
the total amount of bandwidth consumed by students to 40 kbps. 

CLI commands: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) create mp3 
SGOS# (config bandwidth-management) edit mp3 
SGOS# (config bw-class mp3) max-bandwidth 40 

CPL: 

define condition student_mp3_weekday 

client_address =student_subnet response_header . Content-Type="audio/ 
mpeg" \ 

weekday=l . . 5 hour=9 . . 16 
end condition 

<proxy> 

condition=student_mp3_weekday limit_bandwidth . server . inbound (mp3 ) 

Example Two: CPL 

In this example, an administrator must restrict the amount of bandwidth used by 
HTTP POST requests for file uploads from clients to 2 Mbps. The CPL trigger 
used is request method, and the action taken is to throttle (limit) the amount of 
bandwidth used by client side posts by limiting inbound client side flows. 

CLI: 
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SGOS# (config) bandwidth-management 

bandwidth-management) create http_post 

SGOS# (config bandwidth-management) edit http_post 

SGOS# (config bw-class http_post) max-bandwidth 2000 

CPL: 

define condition http_posts 
http ,method=POST 
end condition 

<proxy> 

condition=http_posts limit_bandwidth . client . inbound (http_post) 

Example Three: CPL 

In this example, the administrator of a remote site wants to limit the amount of 
bandwidth used to pre-populate the content from headquarters to 50 kbps during 
work hours. The CPL triggers used are current-time and pre-population 
transactions. The action taken is to limit the total amount of bandwidth consumed 
by pre-pop flows. 

CLI: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) create pre-pop 
SGOS# (config bandwidth-management) edit pre-pop 
SGOS# (config bw-class pre-pop) max-bandwidth 50 

CPL: 

define condition prepop_weekday 

content_management=yes weekday=l . . 5 hour=9..16 
end condition 

<proxy> 

condition=prepop_weekday limit_bandwidth . server . inbound (pre-pop) 
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This chapter discusses device authentication, which is a mechanism that allows 
devices to verify each others' identity; devices that are authenticated can be 
configured to trust only other authenticated devices. 



Note: ProxySG authentication is always used in association with other SGOS 
features. For example, you can use appliance authentication with the ADN 
implementation of secure tunnels. The secure tunnels feature uses 
authentication, the process of verifying a device's identity, with authorization, 
the process of verifying the permissions that a device has. For information on 
secure tunnels and appliance authentication, see Section E: "Securing the ADN 
Network" on page 46. 



Introduction 

Device authentication is important in several situations: 

□ Securing the network. Devices that are authenticated have exchanged 
certification information, verified each others' identity and know which 
devices are trusted. 

□ Securing protocols. Many protocols require authentication at each end of 
the connection before they are considered secure. 

Topics in this Chapter 

This chapter includes information about the following topics: 
a "ProxySG Appliance Overview" 

□ "Appliance Certificates and SSL Device Profiles" on page 116 

□ "Creating an SSL Device Profile for Device Authentication" on page 122 

□ "Related CLI Syntax to Manage Device Authentication" on page 124 

□ "Obtaining a Non Blue Coat Appliance Certificate" on page 121 

□ "Related CLI Syntax to Manage Device Authentication" on page 124 

ProxySG Appliance Overview 

The Blue Coat implementation allows devices to be authenticated without 
sending passwords over the network. Instead, a device is authenticated 
through certificates and SSL device profiles that reference the certificates. Both 
the profile and the referenced certificate are required for device authentication. 

□ Certificates: Certificates contain information about a specific device. Blue 
Coat runs an Internet-accessible Certificate Authority (CA) for the purpose 
of issuing appliance certificates to SGOS devices. You can also create your 
own appliance certificates. 
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□ Profiles: A profile is a collection of information used for several purposes, 
such as device-to-device authentication or when the ProxySG is an SSL 
endpoint for non-proxy traffic. 

Three built-in profiles exist: The profile for device authentication is called 
bluecoat-appliance-certificate and references the appliance certificate on your 
ProxySG. The profile can indicate whether the device has a certificate and if 
the certificates of other devices should be verified. You can create other 
profiles to change the default settings. 



Note: Authenticating the ProxySG appliance and authenticating the ProxySG 
appliance server name are two different procedures that require two different 
certificates. For information on authenticating server names, refer to Volume 4: 
Securing the Blue Coat ProxySG Appliance. 



Appliance Certificates and SSL Device Profiles 

In the Blue Coat implementation of device authentication, both an appliance 
certificate and an SSL device profile that references the appliance certificate 
keyring are required for device authentication to be successful. Each device to be 
authenticated must have an appliance certificate and a profile that references that 
certificate. 

Note that device authentication does not take effect unless the SSL device profile 
is enabled; for example, if you use WAN optimization, you enable the profile on 

the Configuration > ADN > General > Device Security tab. 

About ProxySG Appliance Certificates 

ProxySG appliances come with a cryptographic key that allows the system to be 
authenticated as an ProxySG appliance when an appliance certificate is obtained. 

An appliance certificate is an X.509 certificate that contains the hardware serial 
number of a specific ProxySG as the CommonName (CN) in the subject field. This 
certificate then can be used to authenticate the ProxySG appliance whose 
hardware serial number is listed in the certificate. Information from the presented 
certificate is extracted and used as the device ID. 

Blue Coat runs an Internet-accessible CA for the purpose of issuing appliance 
certificates. The root certificate for the Blue Coat CA is automatically trusted by 
SGOS for device authentication. These Blue Coat-signed certificates contain no 
authorization information and are valid for five years. 

You can provide your own device authentication certificates for the ProxySG 
appliances on your network if you prefer not to use the Blue Coat CA. 

About SSL Device Profiles 

An SSL device profile contains the information required for device authentication: 

□ The name of the keyring that contains the private key and certificate this 
device uses to authenticate itself. The default keyring is appliance-key. (For 
information on private and public keys, refer to Volume 4: Securing the Blue 
Coat ProxySG Appliance.) 
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□ The name of the CA Certificate List (CCL) that contains the names of 
certificates of CAs trusted by this profile. If another device offers a valid 
certificate signed by an authority in this list, the certificate is accepted. The 
default is appiiance-cci. For information on CCLs, refer to Volume 4: Securing 
the Blue Coat ProxySG Appliance. 

□ Verification of the peer certificate. 

When the ProxySG is participating in device authentication as an SSL client, 
the peer certificate verification option controls whether the server certificate is 
validated against the CCL. If verification is disabled, the CCL is ignored. 

When the ProxySG is participating in device authentication as an SSL server, 
the peer certificate verification option controls whether to require a client 
certificate. If verification is disabled, no client certificate is obtained during the 
SSL handshake. The default is verify-peer-certificate enabled. 

□ Specification of how the device ID authorization data is extracted from the 
certificate. The default is $ ( subject. cn) . 

□ SSL cipher settings. The default is AES256-SHA. 

Each Blue Coat appliance has an automatically-constructed profile called bluecoat- 
appliance-certificate that can be used for device-to-device authentication. This 
profile cannot be deleted or edited. 

If you cannot use the built-in profile because, for example, you require a different 
cipher suite or you are using your own appliance certificates, you must create a 
different profile, and have that profile reference the keyring that contains your 
certificate. 



Note: If you do not want to use peer verification, you can use the built-in passive- 
attack-detection-only profile in place of the bluecoat-appliance-certificate profile. 

This profile uses a self-signed certificate and disables the verify-peer option, so 
that no authentication is done on the endpoints of the connection. The traffic is 
encrypted, but is vulnerable to active attacks. 

This profile can be used only when there is no threat of an active man-in-the- 
middle attack. Like the bluecoat-appliance certificate profile, the passive-attack- 
detection-only profile cannot be edited or deleted. 



If you create your own profile, it must contain the same kind of information that is 
contained in the Blue Coat profile. To create your own profile, skip to "Creating an 
SSL Device Profile for Device Authentication" on page 122. 

Obtaining a ProxySG Appliance Certificate 

In many cases, if you have Internet connectivity, an appliance certificate is 
automatically fetched by the ProxySG, and no human intervention is required. In 
other cases, if the Internet connection is delayed or if you do not have Internet 
access, you might have to manually initiate the process of obtaining an appliance 
certificate. 
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How you obtain an appliance certificate depends upon your environment: 

□ If the device to be authenticated has Internet connectivity and can reach the 
Blue Coat CA server, continue with "Automatically Obtaining an Appliance 
Certificate" on page 118. 

□ If the device to be authenticated cannot reach the Blue Coat CA server, you 
must acquire the certificate manually; continue with "Manually Obtaining an 
Appliance Certificate" on page 119. 

After the certificate is obtained, you must configure the device to use the profile 
you choose to use. For information on configuring the device to use the profile, 
see Chapter 2: "Configuring an Application Delivery Network". 

If you are configuring device authorization as well as authentication, configure 
device authentication before authorization. For more information on device 
authorization, see Chapter 2: "Configuring an Application Delivery Network". 



Important: Only the following ProxySG platforms support appliance certificates: 

□ SG200 (manufactured after August 1, 2006) 

□ SG210 

□ SG510 

□ SG810 

□ SG8100 

If you attempt to obtain an appliance certificate for other platforms (through 

Configuration > SSL > Appliance Certificates > Request appliance certificate), the request 
fails with the following error message: 

□ Request failed: Signing server reported error: No such serial number serial number. 

If you receive this message, you cannot use Blue Coat appliance certificates, but 
you can create your own appliance certificates for use in a secure network. For 
more information, see "Obtaining a Non Blue Coat Appliance Certificate" on page 
121 . 



Automatically Obtaining an Appliance Certificate 

The appliance attempts to get the certificate completely automatically (with no 
user intervention) if it can connect to the Blue Coat CA server at boot time or 
within about five minutes of being booted. If the appliance does not have a 
certificate (for example, it had one until you did a restore-defaults factory- 
defaults command) it attempts to get one on every boot. Once the appliance gets 
a certificate, that certificate is used until another restore-defaults factory- 
defaults command is issued. 

If Internet connectivity is established more than five minutes after the system is 
booted, you might need to complete the following steps. 
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To automatically obtain an appliance certificate: 

1. Select Configuration > SSL > Appliance Certificates > Request Certificate. 

2. Click Request appliance certificate. 

The Blue Coat CA server does validation checks and signs the certificate. The 
certificate is automatically placed in the appliance-key keyring. Note that the 
appliance-key keyring cannot be backed up. The keyring is re-created if it is 
missing at boot time. 

Manually Obtaining an Appliance Certificate 

Complete the following steps to obtain an appliance certificate manually. The 
overview of the procedure is to: 

□ Generate a appliance certificate signing request and send it to the Blue Coat 
CA server for verification and signature. 

□ Import the signed certificate into the ProxySG. 

To generate a CSR: 

1. Select Configuration > SSL > Appliance Certificates > Request Certificate. 

2. Select Create CSR. 




3. Copy the certificate request, including the certificate request signature. Be 
sure to include the Begin certificate and End Certificate statements, as 
well as the Begin CSR Signature and End CSR Signature statements. 

4. Click OK. 

5. Go to the Blue Coat CA Server Website at https: / / abrca.bluecoat.com/ sign- 
manual/ index.html. 
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Blue Coat - ABRCA Manual Form 



CSR+Signature 



| BEGIN CERTIFICATE REQUEST 

MIIBxzCC AT AC AQAwgYYx C z A J B gNVB A YT A lVTMQs wC Q YD VQQ IEwJD QTE S MB AG A 1 UE 
BxMJU3Vubnl2 YUxlMS A wHg YD VQQKE x dCb HV 1 1 ENv YXQgU3 1 z dGVt c y ugS ¥5 j Lj E f 
HBOGAlUECxHUQmx 1 ZSBDb2 FOIFNHMj AwIFNlcml lc zETMBEGA1UEAxMKNDUwNTA 2 
HD Ay MD C B n z ANB gkqhk i G9 wO B AQE F A AOB j Q A wg YkC gYEAtlY3 Salts 6ADY8BP YhVb 
HrvA/ aRs0Ed60C wwsux iFSTHn3 i j Dug5ttT5DDvf mxy4 YcgP7vdTaeVdqeQDBwkM 
Fp j xx¥f j THXINgeB¥KhTH8¥LcO/ gBa8 z7c¥Ur yxyGS9FS3 H2 ZB 2XSxSvQT19 z¥u3 
2 XA3 Qt I lr8RH7HHldbPomr OC AwE AAaAAHAOGCSqGS Ib3 DQEBB AUAA4GB AHB ikVOc 
T j M8 zDmPtt I I7dHNCwmf P Iy3 zeyppdr HFL 1 JcnJ j wqhlXr ndN7¥HYUXEwhYJtU9p 
70kyFs+giBt Izdd8f nZaeF4JXNCzSf Lq¥npKOjTBA9¥LTMclThlHplUZE/TllDRS 
kZ6AfyhJQGhxmKuAi8LLRjPHO5Y0owxo8A17 

END CERTIFICATE REQUEST 

BEGIN CSR SIGNATURE 

Ksr qFGa5 jb2 Az+GL/ Hm90FmmB zLgOsvAwBbaYD 64qNm3 VH17ADaMw2 Lf r Z ID 13 e z 
B Ogx K J E B U5 w7 TUL G2 3 Q J V3 Xp wP 7 XOb 6ms 1 e kg/ XPN Z 2 OmoN j 1 3 Vr e J + A9 us Yp Uhh 
5 6qFKf Ic ivnDchukr hl= 

END CSR SIGNATURE 



6. Paste the CSR and signature into the CSR panel. 



7. Click Generate Cert. 



The signed certificate displays, and can be pasted into the appliance-key 
keyring. 

BEGIN CERTIFICATE 

MI I F/ j CCBOagAw I BAg I CAMowDQ Y JKo Z I hvcNAQE FBQAwgb YxC z A JBgNVBAYTAlVT 
MRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTdW5ueXZhbGUxIDAeBgNV 
BAoTFO JsdWUgQ2 9hdCBTeXN0ZWlzLCB JbmMuMRkwFwYDVQQLExBCbHVlIENvYXQs 
IEFCUkNBMRswGQYDVQQDEx JhYn Jj YS5ibHVlY2 9hdC5 jb2 Ox JDAiBgkqhkiG9wOB 
CQEWFXN5c2FkbWluQGJsdWVjb2F0LmNvbTAeFw0wNzAxMj kyMDM5NDda FwOxMj Ax 
Mj kyMDM5NDdaMIGGMQswCQYDVQQGEwJVUzELMAkGAlUECBMCQ0ExE j AQBgNVBAcT 
CVNlbm55dmFsZTEgMB4GAlUEChMXQmxlZSBDb2F0IFN5c3RlbXMsIEluYy4xHzAd 
BgNVBAsTFkJsdWUgQ2 9hdCBTRzIwMCBTZXJpZXMxEzARBgNVBAMTC j AlMDUwNj Aw 
OTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMBUmCuKSsSd+D5kJQiWu3OG 
DNLCvf 7SyKK5+SBC JU2iKwP5+Ef iQ5 JsScWJghtIo94EhdSC2zvBPQqWbZAJXN7 4 
k/ yM4w9uf j f o+G7xPYcMrGmwVBGnXbEhQkagclFH2or INNY8SVDYVLlV4dRM+0at 
YpEiBmSxipmRSMZL4kqtAgMBAAGj ggLGMIICw j AJBgNVHRMEAj AAMAsGAlUdDwQE 
AwIE8DBOBgNVHSUERzBFBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMEBgsr 
BgEEAfElAQECAQYLKwYBBAHx JQEBAgIGCysGAQQB8SUBAQIDMB0GAlUdDgQWBBSF 
NqC2ubTI70T5 j +KqCPGlSDO7DzCB6wYDVR0 j BIH jMIHggBSwEYwcqlN6Gl ZhpcXn 
OTIu8 fNelaGBvKSBuTCBt j ELMAkGAlUEBhMCWMxEzARBgNVBAgTCkNhbGlmb3 Ju 
aWExE j AQBgNVBAcTCVNlbm55dmFsZTEgMB4GAlUEChMXQmxl ZSBDb2F0IFN5c3Rl 
bXMsIEluYy4xGTAXBgNVBAsTEE JsdWUgQ2 9hdCwgQUJSQ0ExGzAZBgNVBAMTEmFi 
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cmNhLmJsdWVjb2F0LmNvbTEkMCIGCSqGSIb3DQEJARYVc31zYWRtaW5AYmxlZWNv 
YXQuY29tggkAhmhbUPEEb60wgZ8GCCsGAQUFBwEBBIGSMIGPMEkGCCsGAQUFBzAB 
hj lodHRwczovL2FicmNhLmJsdWVjb2F0LmNvbS9 j Z2ktYmluL2Rldml j ZSlhdXRo 
ZW50aWNhdGlvbi 9vY3NwMEIGCCsGAQUFBzACh j ZodHRwOi8vYWJyY2EuYmxl ZWNv 
YXQuY2 9tL2Rldml j ZSlhdXRoZW50aWNhdGlvbi9 j YS5 j Z2kwSAYDVR0fBEEwPzA9 
oDugOYY3aHROcDovL2FicmNhLmJsdWVjb2FOLmNvbS9kZXZpY2UtYXVOaGVudGlj 
YXRpb24vQlJMLmNybDBfBgNVHSAEWDBWMFQGCisGAQQB8SUBAQEwRj BEBggrBgEF 
BQcCARY4aHR0cDovL2FicmNhLmJsdWVjb2F0LmNvbS9kZXZpY2UtYXV0aGVudGlj 
YXRpb24vcnBhLmh0bWwwDQYJKoZIhvcNAQEFBQADggEBACIhQ7Vu6aGJBpxP255X 
d2/ Qw7NiVsnq01Ay913QZlieFfVAT JnCeSrH+M9B/2XtnRxVT0/ZWr f 4GbsdYqTF 
he 9 jR/IwKu6kZq32Dqo8qFU50zbAEzT2oebB5QgwuJtHcJHggp9PS9uS27qAnGQK 
0eB2bYc j WtMvTvr50iDOV6 9BEQz+VXos8QiZmRHLVnebQS j 13bilw3Vj Bw31tCmc 
clgz0SlN9ZmJdRU/PlWdNVqD4OLqcMZQ53HqcdWNEzN2uvigIb//rM7XazK7xIaq 
r23/+BsZlYKAeVMq3PEmxaA2 zLzO+ j f 7 9a8 ZvIKrF27nNuTN7NhFL/V6pWNElo9A 
rbs = 

END CERTIFICATE 

To import a certificate onto the ProxySG appliance: 

1. Copy the certificate to your clipboard. Be sure to include the Begin 
Certificate and End Certificate Statements. 

2. Select Configuration > SSL > Keyrings. 

3. Select the keyring that is used for device authentication. The keyring used by 
the bluecoat-appliance-certificate profile is the appliance-key keyring. 

4. Click Edit in the Keyrings tab. 

5. In the Certificate panel, click Import. 

6. Paste the certificate you copied into the dialog box. 

7. Click Close. 

Obtaining a Non Blue Coat Appliance Certificate 

If you run your own certificate signing authority for device authentication, 

complete the following steps: 

1. Create a keyring for the appliance's certificate. For information on creating a 
keyring, refer to Volume 4: Securing the Blue Coat ProxySG Appliance. 

2. Generate the certificate signing request and get it signed. For information on 
creating a CSR, refer to Volume 4: Securing the Blue Coat ProxySG Appliance. 
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Note: You cannot put a Blue Coat appliance certificate into a keyring you 
create yourself. 



3. Create a CA certificate list.For information on creating a CCL, refer to Volume 
4: Securing the Blue Coat ProxySG Appliance. 

a. Import the CA's root certificate. 

b. Add the certificate to the CCL. 

4. Create a device authentication profile. (To create a profile, see "Appliance 
Certificates and SSL Device Profiles" on page 116.) 

5. Associate the profile with the keyring and CCL. The keyring and CCL must 
already exist. 

Adjust other parameters, including authorization data extractor (if the 
certificate is to be used for authorization), as needed. 

Configure each application that uses device authentication to reference the newly 
created profile, and set up its whitelist. To associate the device with the profile, see 
Chapter 2: "Configuring an Application Delivery Network". 

Creating an SSL Device Profile for Device Authentication 

An SSL device profile only needs to be created if you cannot use the built-in 
bluecoat-appliance-certificate profile without modification; note that the bluecoat- 
appliance-certificate profile cannot be deleted or edited. 

Additional profiles with different settings can be created; for example, if you 
require a different cipher setting than what the bluecoat-appliance-certificate profile 
uses, you can create a profile with the different cipher suite. 

To create a new authentication profile: 

1. Select Configuration > SSL > Device Profiles > Profiles. 

2. Click New. 



122 



Chapter 6: Authenticating a ProxySG 




3. Name: Give the profile a meaningful name. The only valid characters are 
alphanumeric, the underscore, and hyphen, and the first character must be a 
letter. 

4. SSL protocol versions: Change the default from SSLv2v3TLSv1 to any other 
protocol listed in the drop-down list. 

5. Keyring: From the drop-down list, select the keyring you want to use for device 
authentication. 



Note: ou must create a new keyring for device authentication if you do not use 
the appliance- key keyring. The keyrings shipped with the ProxySG are dedicated 
to other purposes. For information on creating a new keyring, refer to Volume 4: 
Securing the Blue Coat ProxySG Appliance. 



6. CCL: From the drop-down list, select the CA Certificate List you want to use. 

7. Device ID extractor: The field describes how device ID information is extracted 
from a presented certificate. The string contains references to the attributes of 
the subject or issuer in the form $ (subject, at tr[ . n] ) or $ (issuer. a ttr[ .n] ) , 
where at tr is the short-form name of the attribute and n is the ordinal 
instance of that attribute, counting from 1 when the subject is in LDAP (RFC 
2253) order. If n is omitted, it is assumed to be 1. 

The default is $ ( subj ect . cn) ; many other subject attributes are recognized, 
among them ou, o, l, st, c, and dc. 

8. Verify peer: This setting determines whether peer certificates are verified 
against the CCL or whether client certificates are required. 
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9. Selected ciphers: To use a different cipher suite: 

a. click Edit ciphers. 

b. Select the ciphers and click Add to add the cipher to the list of selected 
cipher suites. Cipher suites that you do not want to use should be 
removed from the selected list. 

10. Click OK to close the dialog. 

11. Click Apply. 

Related CLI Syntax to Manage Device Authentication 

□ To enter configuration mode: 

SGOS# (config) ssl 

□ The following SSL device profile commands are available: 

SGOS# (config ssl) create ssl-device-prof ile profile_name keyring_ID 
SGOS# (config ssl) edit ssl-device-prof ile test 

SGOS# (config device-profile test) cipher-suite cipher-suite 
SGOS# (config device-profile test) ccl ccl_name 
SGOS# (config device-profile test) device-id device_ID 
SGOS# (config device-profile test) exit 

SGOS# (config device-profile test) keyring-id keyring^ID 

SGOS# (config device-profile test) protocol {sslv2 | sslv3 | tlsvl | 

sslv2v3 | sslv2tlsvl | sslv3tlsvl | sslv2v3tlsvl } 

SGOS# (config device-profile test) verify-peer [enable | disable] 
SGOS# (config device-profile test) view 
SGOS# (config ssl) request-appliance-certificate 
SGOS# (config ssl) view appliance-certificate-request 
SGOS# (config ssl) view ssl-device-prof ile 
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Using IP address failover, you can create a redundant network for any explicit 
proxy configuration. If you require transparent proxy configuration, you can 
create software bridges to use failover. For information on creating software 
bridges, refer to Volume 1: Getting Started. 



Note: If you use the Pass-Through adapter for transparent proxy, you must 
create a software bridge rather than configuring failover. For information on 
using the Pass-Through adapter, refer to Volume 1: Getting Started. 



Using a pool of IP addresses to provide redundancy and load balancing. Blue 
Coat moves these IP addresses among a group of machines. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ "About Failover" 

□ "Configuring Failover" on page 126 

About Failover 

Failover allows a second machine to take over if a first machine (not just an 
interface card) fails, providing redundancy to the network through a master/ 
slave relationship. In normal operations, the master (the machine whose IP 
address matches the group name) owns the address. The master sends 
keepalive messages ( advertisements ) to the slaves. If the slaves do not receive 
advertisements at the specified interval, the slave with the highest configured 
priority takes over for the master. When the master comes back online, the 
master takes over from the slave again. 

The Blue Coat failover implementation resembles the Virtual Router 
Redundancy Protocol (VRRP) with the following exceptions: 

□ A configurable IP multicast address is the destination of the 
advertisements. 

□ The advertisement interval is included in protocol messages and is learned 
by the slaves. 

□ A virtual router identifier (VRID) is not used. 

□ Virtual MAC addresses are not used. 

□ MD5 is used for authentication at the application level. 
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Masters are elected, based on the following factors: 

□ If the failover mechanism is configured for a physical IP address, the machine 
owning the physical address have the highest priority This is not 
configurable. 

□ If a machine is configured as a master using a virtual IP address, the master 
has a priority that is higher than the slaves. 

When a slave takes over because the master fails, an event is logged in the event 
log. No e-mail notification is sent. 

Configuring Failover 

Before you begin, ensure that software bridges already exist. For information on 
configuring bridges, refer to Volume 1: Getting Started. 

You also must decide which machine is the master and which machines are the 
slaves, and whether you want to configure explicit proxy or transparent proxy 
network. 

When configuring the group, the master and all the systems in the group must 
have exactly the same failover configuration except for priority, which is used to 
determine the rank of the slave machines. If no priority is set, a default priority of 
100 is used. If two appliances have equal priority, the one with the highest 
physical address ranks higher. 



Note: Configuring failover on an Application Data Network (ADN) is similar to 
configuring failover on other appliances, with the exception that you add a server 
subnet on multiple boxes instead of just one. 



To configure failover: 

1. Select Configuration > Network > Advanced > Failover. 

2. Click New. 
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3. Create a group using either a new IP address or an existing IP address. If the 
group has already been created, you cannot change the new IP address 
without deleting the group and starting over. 

4. Configure group options: 

a. Multicast address refers to a Class D IP address that is used for multicast. 

It is not a virtual IP address. 



Note: Class D IP addresses (224 to 239) are reserved for multicast. A 
Class D IP address has a first bit value of 1, second bit value of 1, third bit 
value of 1, and fourth bit value of 0. The other 28 bits identify the group 
of computers that receive the multicast message. 



b. Relative Priority refers to a range from 1-255 that is assigned to systems 
in the group. 255 is reserved for the system whose failover group ID 
equals the real IP address. (Optional) Master identifies the system with 
the highest priority (the priority value is greyed out). 

c. (Optional) Advertisement Interval refers to the length of time between 
advertisements sent by the group master. The default is 40 seconds. If 
the group master fails, the slave with the highest priority takes over 
(after approximately three times the interval value). The failover time 
of the group is controlled by setting this value. 

d. (Optional, but recommended) Group Secret refers to a password shared 
only with the group. 

5. Select enabled. 

6. Click OK to close the dialog. 

7. Click Apply. 
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Related CLI Syntax to Configure Failover 



□ To enter configuration mode: 

SGOS# (config) failover 

□ The following subcommands are available: 



SGOS# (config failover) create group_address 



SGOS# (config failover) 
SGOS# (config failover 
multicast_address 
SGOS# (config failover 
SGOS# (config failover 
SGOS# (config failover 
SGOS# (config failover 
-or- 

SGOS# (config failover 
SGOS# (config failover 



edit groupaddress 
groupaddress) multicast-address 



groupaddress) 

group^address) 

groupaddress) 

group_address) 



master 

priority number 
interval seconds 
secret secret 



group_address) encrypted-secret encrypted_secret 
group_address) enable 



Viewing Failover Statistics 

At any time, you can view statistics for any failover group you have configured 
on your system. 

To view failover status: 

1. Select Statistics > System > Failover. 



Status 



Failover Group: 



10 . 9 . 16.150 



v 



r Failover status: 

224 . 1 . 2.3 
10 . 9 . 16.150 
MASTER 
R (Real IP) 



Multicast address: 
Local address: 
State: 

Flags: 



2. From the drop-down list, select the group to view. 

The information displayed includes the multicast address, the local address, the 
state, and any flags, where V indicates the group name is a virtual IP address, R 
indicates the group name is a physical IP address, and M indicates this machine 
can be configured to be the master if it is available. 



Troubleshooting 

An indication that there may be issues with the election of a master is if 
advertisements are not being sent or received by either of the systems in a failover 
group. 

To troubleshoot, view statistics in the command line interface: 

Blue Coat SG200 Series# ( config) failover 

Blue Coat SG200 Series# (config failover ) view statistics 
Failover Statistics 

Advertisements Received : 0 
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Advertisements Sent 



0 



States Changes 
Bad Version 



0 



0 



Bad Packet 



0 



Bad Checksum 



0 



Packet Too Short 



0 



Bad Packet Header 



0 



Invalid Group 



0 



Blue Coat SG200 Series# (config failover) 

If the statistics illustrate there may be a potential issue, debug further by running 
a PCAP on each ProxySG to verify the multicast packets are actually being sent. If 
not, verify the multicast address is configured correctly (Configuration > Network > 
Advanced > Failover). If both proxies are sending the multicast packets but not 
receiving them, it is possible that a switch/ router is blocking multicast packets. 
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This chapter describes how to configure the ProxySG to interact with both the 
local network and with the upstream network environment. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ Section A: "Overview" on page 132 

□ Section B: "About Forwarding" on page 133 

□ Section C: "Configuring Forwarding" on page 136 

□ Section D: "Using Forwarding Directives to Create an Installable List" on 
page 144 
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Section A: Overview 

To control upstream interaction, the ProxySG appliance supports: 

□ The ProxySG forwarding system — Allows you to define the hosts and groups 
of hosts to which client requests can be redirected. Those hosts can be servers 
or proxies. Rules to redirect requests are set up in policy. 

□ SOCKS gateways — SOCKS servers provide application-level firewall 
protection for an enterprise. The SOCKS protocol provides a generic way to 
proxy HTTP and other protocols. For information on configuring SOCKS 
gateways, see Chapter 13: "SOCKS Gateway Configuration" on page 327. 

□ ICP — ICP handles ICP queries from other caching devices looking for cached 
data. The ProxySG appliance also can use ICP. For information on configuring 
ICP, see Chapter 9: "Internet Caching Protocol (ICP) Configuration" on page 
153. 
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Section B: About Forwarding 

Fonvarding allows you to redirect requests to IP addresses other than those 
specified in the URL. Forwarding also allows you to organize how the Web traffic 
flows around the network. Forwarding does not affect the URL that appears in the 
request. It only affects the IP address of the upstream device a request is sent to. 

The ProxySG forwarding system consists of forwarding, upstream SOCKS 
gateways, load balancing, host affinity, health checks, and ICP The ProxySG 
appliance forwarding system determines the upstream address where a request is 
sent, and is tied in with all the protocol agents, including HTTP, HTTPS, 
streaming, and FTP, and the network configuration. The combination of 
forwarding and the policy engine allows traffic management and flexible 
configuration. 



Note: The ProxySG forwarding system directly supports the forwarding of HTTP, 
HTTPS, FTP, Windows Media, RTSP, Telnet, and TCP tunnels. 



About Load Balancing 

Load balancing is a way to share traffic requests among multiple upstream systems 
or multiple IP addresses on a single host. Load-balancing methods include round 
robin, which selects the next system in the list, or least connections, which selects 
the system with the least number of connections among the selected group. 

You can configure load balancing two ways: 

□ For individual hosts: If a host is DNS-resolved to multiple IP addresses, then 
that host's load-balancing method (round robin, least connections, or none) is 
applied to those IP addresses. The method is either explicitly set for that host 
or taken from the configurable global default settings. 

□ For groups: Load balancing for groups works exactly the same as load 
balancing for hosts with multiple IP addresses — the forwarding system 
collects all of the IP addresses for all of the hosts in the group and load 
balances over that set using the method that is specified. You can also use a 
domain or URL hash, as well. 

About Host Affinity 

Host affinity is the attempt to direct multiple connections by a single user to the 
same group member. Host affinity is closely tied to load balancing behavior; both 
should be configured if load balancing is important. For example, a Web site uses 
shopping carts to allow customers to purchase items. The site might use load 
balancing with a group of Web servers working in parallel, but only one server in 
the group has information on a single user. If the user connections are sent to a 
different server, the server has no previous information on the user and might 
start over. 
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Host affinity forces the user's connections to return to the same server until the 
user is idle. After a configurable period of inactivity the host affinity times out 
and the association of multiple connections with that single user is lost. 

Host affinity allows you to use the following options: 

□ Use the client IP address to determine which group member was last used. 
When the same client IP sends another request, the host makes the connection 
is made to that group member. 

□ Place a cookie in the response to the client. When the client makes further 
requests, the cookie data is used to determine which group member the client 
last used. The host makes the connection to that group member. 

□ For HTTPS, extract the SSL session ID name from the connection information. 
The host uses the session ID in place of a cookie or client IP address to 
determine which group member was last used. The host makes the connection 
to that group member. 

Using Load Balancing with Host Affinity 

By default, if you use load balancing, each connection is treated independently. 
The connection is made to whichever member of the load-balancing group that 
the load-balancing algorithm selects. The load balancing responsibility is to 
distribute the connections among group members to share the load. 

If host affinity is configured, the system checks host affinity first to see if the 
request comes from a known client. If this is a first connection, the load-balancing 
algorithm selects the group member to make the connection. Host affinity records 
the result of the load balancing and uses it if that client connects again. 

Host affinity does not make a connection to a host that health checks report is 
down; instead, if host affinity breaks, the load-balancing algorithm selects a group 
member that is healthy and re-establishes affinity on that working group member. 



Note: You might find it necessary to disable caching for traffic sent to the load- 
balanced groups (or hosts if DNS hides a group under one entry) to prevent 
copies of customized Web pages being served to a different user. 

It is not always necessary to disable caching; for example, load balancing can be 
used without host affinity or without disabling caching to distribute load among 
several proxies. 

However, if caching is enabled for traffic going through load balancing, retrieval 
of updated content by the cache is done according to load balancing rules; the 
cache does not support host affinity and ignores it if enabled. 
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Host affinity methods are discussed in the table below. 
Table 8-1 Host Affinity Methods 



Setting 


Description 


HTTP 


SSL 


Other (TCP 
Tunnel or 
Telnet) 


Global Default 


Use the default setting for all 
forwarding hosts on the system. 


X 


X 


X 


None 


Disables host affinity. 


X 


X 


X 


Client IP 
Address 


Uses the client IP address to 
determine which group member 
was last used. 


X 


X 


X 


Accelerator 

Cookie 


Inserts a cookie into the 
response to the client. 


X 


X 




SSL Session ID 


Used in place of a cookie or 
client IP address. Extracts the 
SSL session ID name from the 
connection information. 




X 
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Section C: Configuring Forwarding 

High-level steps to configure forwarding are: 

□ Create the forwarding hosts and groups, including parameters such as 
protocol agent and port. 

□ Set Load Balancing and Host Affinity values. 

Creating Forwarding Hosts and Groups 

You can create as many hosts, groups, or members of a group as you need. 
To create groups, see "To create forwarding groups:" on page 137 

To create forwarding hosts: 

1. Click Configuration > Forwarding > Forwarding Hosts. 

2. Click New. The Add Forwarding Host dialog displays. 




3. Configure the host options: 

a. In the Alias field, enter the name of the host as it will be named in 
policy. 
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Note: The host alias cannot be a CPL keyword, such as no, default, or 
forward. 



b. In the Host field, give the name of the host domain or its IP address. 

c. Define the host type by selecting either the Proxy or Server radio button. 
Terminated HTTPS, TCP tunnels, and Telnet can be forwarded to a 
server only; they cannot be forwarded to a proxy. Server specifies to use 
the relative path for URLs in the HTTP header because the next hop is 
a Web server, not a proxy server. The default is Proxy. 

d. Select the port you want to use. 

Port 80 is the default for HTTP. The rest of the host types default to their 
appropriate Internet default port, except TCP tunnels, which have no 
default and for which a port must be specified. 

e. In the Load Balancing and Host Affinity section, select a load-balancing 
method from the drop-down list. Global default (configured on the 
Configuration > Forwarding > Global Defaults tab), sets the default for all 
forwarding hosts on the system. You can also specify the load- 
balancing method for this system: Least Connections or Round Robin, or 
you can disable load balancing by selecting None. 

f. In the Host affinity methods drop-down list (see Table 8-1, "Host Affinity 
Methods" on page 135), select the method you want to use. 

4. Click OK. 

5. Click Apply. 

To create forwarding groups: 

An existing host can belong to one or more groups as needed. It can only belong 

once to a single group. 

1. Click Configuration > Forwarding > Forwarding Groups. 

2. Click New. The Add Forwarding Group dialog displays, showing the available 

aliases. 
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Forwarding Hosts Forwarding Groups Global Defaults | Default Sequence ] Install Forwarding File 




3. Enter a name for the new group in the Alias field. 

Note: The group alias cannot be a CPL keyword, such as no, default, or 

forward. 



4. To add members to a group, highlight the hosts you want grouped and click 
Add. You can also create a group with no members. 

5. In the Load Balancing and Host Affinity section, select the load-balancing method 
from the drop-down list. Global default (configured on the Configuration > 
Forwarding > Global Defaults tab), are the defaults that were set for all forwarding 
groups on the system. To specify the load-balancing method for this system, 
select Least Connections, Round Robin, Domain Hash, URL Hash, or you can disable 
load balancing by selecting None. 

6. In the Host affinity methods drop-down list (see Table 8-1, "Host Affinity 
Methods" on page 135), select the method you want to use. 

7. Click OK. 

8. Click Apply. 
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Configuring Global Forwarding Defaults 

The global defaults apply to all forwarding hosts and groups unless the settings 
are specifically overwritten during host or group configuration. 

To configure global defaults: 

1. Select Configuration > Forwarding > Global Defaults. 

Forwarding Hosts Forwarding Groups Global Defaults 

r General Settings 

If no forwarding host is available: 

O Connect directly (fail open) 

® Deny the request (fail closed) 

0 Use forwarding for administrative downloads 
Timeout for integrated hosts: 60 minutes 



- Load Balancing and Host Affinity 

Load balancing methods: 




Host affinity timeout: [ 30 minutes 



2. Configure General Settings as follows: 

a. Determine how connections behave if no forwarding is available. 

Failing open is an insecure option. The default is to fail closed. This 
setting can be overridden by policy, if it exists. 

b. Decide if you want to Use forwarding for administrative downloads. The 

default is to use forwarding in this case. 

This option determines whether forwarding is applied to requests 
generated for administrative reasons on the system, such as downloading 
policy files or new system images. 

If the option is on, meaning that forwarding is applied, you can control the 
forwarding in policy as needed. 

This option also affects the use of SOCKS gateways. 

c. Enter the Timeout for integrated hosts interval: An integrated host is an 
Origin Content Server (OCS) that has been added to the health check 
list. The host, added through the integrate new hosts policy property, 
ages out after being idle for the specified time. The default is 60 
minutes. 

3. Configure Global Load Balancing and Host Affinity Settings, 
a. Load-balancing methods: 
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• Forwarding hosts: Specify the load-balancing method for all 
forwarding hosts unless their configuration specifically overwrites the 
global settings. You can choose Least Connections or Round Robin, or you 
can disable load balancing by selecting None. Round Robin is specified 
by default. 

• Forwarding groups: Specify the load-balancing method for all 
forwarding groups unless their configuration specifically overwrites 
the global settings. You can choose to do a domain hash or a URL hash. 
You can also select Least Connections or Round Robin, or disable load 
balancing by selecting None. Round Robin is specified by default. 

b. In the Global Host Affinity methods (see Table 8-1, "Host Affinity 
Methods" on page 135), select the method you want to use. 

c. Enter the Host Affinity Timeout interval, the amount of time a user's IP 
address, SSL ID, or cookie remains valid after its most recent use. The 
default is 30 minutes, meaning that the IP address, SSL ID or cookie 
must be used once every 30 minutes to restart the timeout period. 

4. Click Apply. 

Configuring the Default Sequence 

The default sequence is the default forwarding rule, used for all requests lacking 
policy instructions. Lailover is supported if the sequence (only one is allowed) has 
more than one member. 



Note: Creating the default sequence through the CLI is a legacy feature. You can 
set up sequences by using policy alone. The default sequence (if present) is 
applied only if no applicable forwarding gesture is in policy. 

Lor information on using VPM, refer to Volume 6: The Visual Policy Manager and 
Advanced Policy; for information on using CPL, refer to Volume 10: Content Policy 
Language Guide. Lor information on using forwarding with policy, see 
Appendix A: "Using Policy to Manage Porwarding" on page 419. 



The default sequence (and any sequence specified in policy) works by allowing 
healthy hosts to take over for an unhealthy host (one that is failing its DNS 
Resolution or its health check). If more than one member is in the sequence, the 
sequence specifies the order of failover, with the second host taking over for the 
first host, the third taking over for the second, and so on. 



Note: In normal circumstances, only the first member of the sequence is ever 
used. Traffic is forwarded to the first member of the sequence until it fails, then 
traffic is sent to the second member of list until it fails or the first member 
becomes healthy again, and so on. 
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To create a default sequence: 

1. Select Configuration > Forwarding > Default Sequence. The available aliases are 
displayed. 

Forwarding Hosts | Forwarding Groups ] Global Defaults Default Sequence | Install Forwarding File 

- Default Fail-Over Sequence 

Available Aliases Selected Aliases 

Alias name 



testl 



2. To select an alias, highlight it and click Add. 

Note: Any host or group in the default sequence is considered in use by 
policy. As a result, if you try to delete a host or group while it is in the default 
sequence, you receive an error message. You must remove the host/ group 
from the sequence first, then delete the host or group. 

3. Click Promote or Demote to change the order of the hosts in the failover 
sequence. 

4. Click Apply. 

Related CLI Syntax to Configure Forwarding 

□ To enter configuration mode for forwarding: 

SGOS# (config) forwarding 
SGOS# (config forwarding) 

□ The following subcommands are available: 

SGOS# (config) forwarding 

SGOS# (config forwarding) create host host^alias host_name [http [=port] 
[https [=port] ] [ ftp [=port] ] [mms[=port] ] [rtsp [=port] ] [tcp [=port] ] 

[telnet [=port] ] [ssl-verify-server [=yes | =no] ] [gxoup=group_name] 
[server | proxy] 

SGOS# (config forwarding) create group group^name 

SGOS# (config forwarding) delete all 

SGOS# (config forwarding) delete group group_name 



Add » 



Promote 
Demote 
« Remove 



Alias name 
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SGOS# (config forwarding) delete host host_alias 

SGOS# (config forwarding) download-via-f orwarding {disable | enable} 

SGOS# (config forwarding) edit host^alias 

SGOS# (config forwarding host_alias) exit 

SGOS# (config forwarding host_alias) {ftp | http | https | mms | 
rtsp | tcp | telnet} [port] } 

SGOS# (config forwarding host_alias) host hostname 

SGOS# (config forwarding host_alias) host-affinity http {default | 
none | client- ip-address | accelerator-cookie} 

SGOS# (config forwarding host_alias) host-affinity ssl {default | 
none | client- ip-address | accelerator-cookie | ssl-session-id} 
SGOS# (config forwarding host^alias) host-affinity other {default | 
none | client- ip-address } 

SGOS# (config forwarding host_alias) load-balance method {default | 
least-connections | none | round- robin} 

SGOS# (config forwarding host_alias) no {ftp | http | https | mms | 
rtsp | ssl-verify-server | tcp | telnet} 

SGOS# (config forwarding host_alias) proxy | server 
SGOS# (config forwarding host_alias) ssl-verify-server 
SGOS# (config forwarding host_alias) view 
SGOS# (config forwarding) edit group_alias 

SGOS# (config forwarding group_alias) {add | remove} host_alias 
SGOS# (config forwarding group_alias) exit 

SGOS# (config forwarding group_alias) host-affinity http {default | 
none | client- ip-address | accelerator-cookie} 

SGOS# (config forwarding group^alias) host-affinity ssl {default I 
none | client- ip-address | accelerator-cookie | ssl-session-id} 
SGOS# (config forwarding group^alias) host-affinity other {default | 
none | client- ip-address } 

SGOS# (config forwarding group^alias) load-balance {default | 
domain-hash | least-connections | none | round-robin | url-hash} 

SGOS# (config forwarding groupalias) view 
SGOS# (config forwarding) exit 

SGOS# (config forwarding) failure-mode {closed | open} 

SGOS# (config forwarding) host-affinity http {default I none | client- 
ip-address | accelerator-cookie} host_or_group_alias 

SGOS# (config forwarding) host-affinity http {none | client-ip-address 
| accelerator-cookie} 

SGOS# (config forwarding) host-affinity ssl {default | none | client- 
ip-address | accelerator-cookie | ssl-session-id} host_or_group_alias 

SGOS# (config forwarding) host-affinity ssl {none | client-ip-address | 
accelerator-cookie | ssl-session-id} 

SGOS# (config forwarding) host-affinity other {default | none | client- 
ip-address} host_or_group_alias 

SGOS# (config forwarding) host-affinity other {none | client- ip- 
address } 

SGOS# (config forwarding) host-affinity timeout minutes 
SGOS# (config forwarding) integrated-host- timeout minutes 
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SGOS# (config forwarding) load-balance group {default I none | domain- 
hash | url-hash | round- robin | least-connections} group_alias 
SGOS# (config forwarding) load-balance group {none | domain-hash | url- 
hash | round-robin | least-connections} 



SGOS# (config forwarding) load-balance host {default I none | round- 
robin | least-connections} host_alias 

SGOS# (config forwarding) load-balance host {none | round-robin | 
least-connections } 

SGOS# (config forwarding) no path 
SGOS# (config forwarding) path url 

SGOS# (config forwarding) sequence add host_or_group_alias 
SGOS# (config forwarding) sequence clear 

SGOS# (config forwarding) sequence demote host_or_group_alias 
SGOS# (config forwarding) sequence promote host_or_group_alias 
SGOS# (config forwarding) sequence remove host_or_group_alias 
SGOS# (config forwarding) view 



Statistics 

To view forwarding statistics, select Statistics > Advanced > Forwarding. 
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Section D: Using Forwarding Directives to Create an Installable List 

You can use directives instead of using the Management Console or CLI to 
configure forwarding. Note that the Management Console offers the easiest 
method of configuration. Using directives, you can: 

□ Create the forwarding hosts and groups 

□ Provide load balancing and host affinity 



Table 8-2 Forwarding Directives 



Directive 


Meaning 


See 


fwd fail 


Determines whether the 
forwarding host should fail 
open or fail closed if an 
operation does not succeed. 


"Setting Fail Open/ Closed 
and Host Timeout Values" 
on page 146. 


fwd host 


Creates a forwarding host and 
sets configuration parameters 
for it, including protocols and 
ports. 


"Creating Forwarding 
Hosts" on page 145. 


group 


Creates a forwarding group 
and identifies members of the 
group. 


"Creating Forwarding 
Groups Using Directives" 
on page 146. 


host affinity 


Directs multiple connections 
by a single user to the same 
group member. 


"Configuring Host Affinity 
Directives" on page 148. 


integrated host 
timeout 


Manages an origin content 
server that has been added to 
the health check list. The host 
ages out after being idle for the 
specified time. 


"Setting Fail Open/ Closed 
and Host Timeout Values" 
on page 146. 


load balance 


Manages the load among 
forwarding hosts in a group, 
or among multiple IP 
addresses of a host. 


"Configuring Load- 
Balancing Directives" on 
page 147. 


sequence 


Sets the default sequence to 
the space separated list of one 
or more forwarding host and 
group aliases. (The default 
sequence is the default 
forwarding rule, used for all 
requests lacking policy 
instructions.) 


"Creating a Default 
Sequence" on page 148. 
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Creating Forwarding Host and Group Directives 

A forwarding host directive creates a host along with all its parameters. You can 
include a group that the forwarding host belongs to. 

A group directive creates a group and identifies group members. For more 
information on group directives, skip to "Creating Forwarding Groups Using 
Directives" on page 146. 

Creating Forwarding Hosts 

To create a forwarding host, choose the protocols you want to use and add the 
forwarding host to a group, enter the following into your installable list. Create a 
fwd host directive for each forwarding host you want to create. 

fwd_host host^alias hostname [http [=port] ] [https [=port ] ] [ ftp [=port]] 

[mms [=port] ] [rtsp [=port] ] [tcp=port] [telnet [=port ] ] [ssl-verify- 
server[=yes | =no] ] [group =group_name [server | proxy]] 



Table 8-3 Commands to Create Forwarding Host and Group Directives 



host alias 




This is the alias for use in policy. Define a 
meaningful name. 


hostname 




The name of the host domain, such 
www . bluecoat . com, or its IP address. 


http 

https 


=port 


At least one protocol must be selected 


ftp 

mms 

rtsp 

telnet 




HTTPS and Telnet cannot be used with a proxy. 
Note that HTTPS refers to terminated HTTPS, so 
it is used only for a server. 


top 


=port 


If you choose to add a TCP protocol, a TCP port 
must be specified. 

TCP protocols are not allowed if the host is a 
proxy. 


ssl-verif y- 
server 


=yes | =no 


Sets SSL to specify that the ProxySG checks the 
CA certificate of the upstream server. 

The default for ssl-verif y-server is yes. This 
can be overridden in the SSL layer in policy. 

To disable this feature, you must specify ssl- 
verify-server=no in the installable list or CLI. 
In other words, you can configure ssl-verify- 
server=yes in three ways: do nothing (yes is the 
default), specify ssl-verify-server=no, or 
specify ssl-verify-server=yes. 
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Table 8-3 Commands to Create Forwarding Host and Group Directives (Continued) 



group 


=group name 


Specifies the group (or server farm or group of 
proxies) to which this host belongs. If this is the 
first mention of the group group_name then that 
group is automatically created with this host as its 
first member. 

The ProxySG uses load balancing to evenly 
distribute forwarding requests to the origin 
servers or group of proxies. 


server | proxy 




server specifies to use the relative path for URLs 
in the HTTP header because the next hop is a Web 
server, not a proxy server. The default is proxy. 



Example 

fwd_host www.bluecoatl.com 10.25.36.48 ssl-verif y-server=no 
group=bluecoat 

Creating Forwarding Groups Using Directives 

The forwarding groups directive has the following syntax: 

group group_name host_alias_l host_alias_2 . . . 

where group_name is the name of the group, and host alias i, host, alias 2, and 
so forth are the forwarding hosts you are assigning to the forwarding group. 

Forwarding host parameters are configured through the forwarding host 
directives. 

Setting Special Parameters 

After you configure the forwarding hosts and groups, you might need to set other 
special parameters to fine tune the hosts. You can configure the following settings: 

□ "Setting Fail Open/ Closed and Host Timeout Values". 

□ "Configuring Load-Balancing Directives" on page 147. 

□ "Configuring Host Affinity Directives" on page 148. 

Setting Fail Open/Closed and Host Timeout Values 

Using directives, you can determine if the forwarding host fails open or closed, if 
an operation does not succeed, and the interval it takes for integrated hosts to be 
aged out. 

An integrated host is an Origin Content Server (OCS) that has been added to the 
health check list. If the policy property integrate new hosts applies to a 
forwarding request as a result of matching the integrate new hosts property, the 
ProxySG makes a note of each OCS and starts health checking to help future 
accesses to those systems. If the host is idle for the interval you specify, it is aged 
out. Sixty minutes is the default interval. 
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The syntax is: 

fwd_fail {open | closed} 
integrated host timeout minutes 



Table 8-4 Commands to Set Fail Open/Closed and Host Timeout Values 



fwd fail 


{open | 
closed} 


Determines whether the forwarding host 
should fail open or fail closed if an 
operation does not succeed. Fail open is a 
security risk, and fail closed is the default if 
no setting is specified. 

This setting can be overridden by policy, 
(using the forward. fail open (yes | no) 
property). 


integrated host timeout 


minutes 


An OCS that has been added to the health 
check list is called an integrated host. The 
host ages out after being idle for the 
specified time. 



Examples 

fwd_fail open 

integrated_host_timeout 90 

Configuring Load-Balancing Directives 

Load balancing shares the load among a set of IP addresses, whether a group or a 
host with multiple IP addresses. 

The syntax is: 

load_balance group {none | domain-hash | url-hash | round-robin | 
least-connections} [ groupalias ] 

load_balance host {none | round-robin | least-connections} 

[host alias] 



Table 8-5 Load Balancing Directives 



Command 


Suboptions 


Description 


load balance 
group 


{none | domain-hash | url- 
hash | round-robin | 
least-connections } 

[group alias ] 


If you use group for load balancing, 
you can set the suboption to none or 
choose another method. If you do 
not specify a group, the settings 
apply as the default for all groups. 


load balance 
host 


{none | round-robin | 
least-connections } 

[ host alias] 


If you use host for load balancing, 
you can set the suboption to none or 
choose another method. If you do 
not specify a host, the settings apply 
as the default for all hosts. 



Example 

load balance host least connections 
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Configuring Host Affinity Directives 

Host affinity is the attempt to direct multiple connections by a single user to the 
same group member. 

The syntax is: 

host_af finity http {none | client-ip-address I accelerator-cookie} 

[ host_or_group_alias ] 

host_af finity ssl {none | client-ip-address I accelerator-cookie I 
s si -session- id} [ host_or^group_alias ] 

host_af finity other {none I client-ip-address} [ host_or_group_alias ] 
host_af finity timeout minutes 



Table 8-6 Commands to Configure Host Affinity Directives 



Command 


Suboption 


Description 


host affinity 
http 


{accelerator-cookie | 
client-ip-address | none} 
[ host or group alias] 


Determines which HTTP host- 
affinity method to use 
(accelerator cookie or client- 
ip-address), or you can specify 
none. If you do not specify a host or 
group, the settings apply as the 
default for all hosts or groups. 


host affinity 
ssl 


{accelerator-cookie | 
client-ip-address | none 
I ssl-session-id} 

[ host or group alias] 


Determines which SSL host-affinity 
method to use (accelerator 
cookie, client-ip-address, or 
ssl-session-id), or you can 
specify none. If you do not specify a 
host or group, the settings apply as 
the default for all hosts or groups. 


host affinity 
other 


{none | client-ip- 
address } 

[ host or group alias] 


Determines whether client-ip- 
address mode is used with TCP 
tunnels or Telnet. 


host affinity 
timeout 


minutes 


Determines how long a user's IP 
address, SSL ID, or cookie remains 
valid when idle 



Example 

host_af finity ssl_method 10.25.36.48 
host_af finity timeout 5 

Creating a Default Sequence 

The default sequence is the default forwarding rule, used for all requests lacking 
policy instructions. Failover is supported if the sequence (only one is allowed) has 
more than one member. 



Note: The default sequence is completely overridden by policy. 
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A default failover sequence works by allowing healthy hosts to take over for an 
unhealthy host (one that is failing its DNS resolution or its health check). The 
sequence specifies the order of failover, with the second host taking over for the 
first host, the third taking over for the second, and so on). 

If all hosts are unhealthy, the operation fails either open or closed, depending 
upon your settings. 

This configuration is generally created and managed through policy. If no 
forwarding policy applies, you can create a default sequence through the CLI. 
This single default sequence consists of a single default host (or group) plus one 
or more hosts to use if the preceding ones are unhealthy. 

The syntax is: 

sequence alias^list 

where ai±as_iist is a space-separated list of one or more forwarding host 
and group aliases. 

Example 

sequence bluecoat 

Creating a Forwarding Installable List 

You can create and install the forwarding installable list using one of the 
following methods: 

□ Text Editor, which allows you to enter the installable list of directives (or copy 
and paste the contents of an already-created file) directly onto the appliance. 

□ A local file, created on your system; the ProxySG can browse to the file and 
install it. 

□ A remote URL, where you placed an already-created file on an FTP or HTTP 
server to be downloaded to the ProxySG. 

□ CLI inline command. 

When the Forwarding Installable List is installed, it replaces the forwarding 
configuration on the ProxySG. The configuration remains in effect until 
overwritten by another installable list; the configuration can be modified or 
overwritten using CLI commands. 



Note: During the time that a forwarding installable list is being compiled and 
installed, forwarding might not be available. Any transactions that come into the 
ProxySG during this time might not be forwarded properly. 



Installation of forwarding installable lists should be done outside peak traffic 
times. 
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To create a forwarding installable list: 

1. Select Configuration > Forwarding > Install Forwarding File. 

2. From the drop-down list, select the method to use to install the forwarding 
installable list; click Install. 



Note: A message is written to the event log when you install a list through 
the SGOS software. 



• Remote URL: 

Enter the fully-qualified URL, including the filename, where the 
installable list is located. To view the file before installing it, click View. 
Click Install. Examine the installation status that displays; click OK. 

• Local File: 

Click Browse to display the Local File Browse window. Browse for the 
installable list file on the local system. Open it and click Install. When the 
installation is complete, a results window opens. View the results, close 
the window, click Close. 

• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the 
installation 

is complete, a results window opens. View the results, close the window, 
click Close. 



Note: The Management Console text editor is a way to enter an 
installable list for forwarding. It is not a way to enter CLI commands. The 
directives are understood only by the installable list parser for 
forwarding. 



3. Click Apply. 

Note: You can create forwarding settings using the CLI #iniine forwarding 
command. You can use any of the forwarding directives. 

For more information on using inline commands, refer to Volume 11: Command 
Line Interface Reference. 



To delete forwarding settings on the ProxySG: 

From the (config) prompt, enter the following commands to delete a host, a 
group, or all hosts and groups from the forwarding configuration: 

SGOS# (config) forwarding 

SGOS# (config forwarding) delete {all | group group_name I host 
host_alias} 
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Note: : Any host or group in the default sequence (or the DRTR service 
configuration) is considered in use by policy As a result, if you try to delete a host 
or group while it is in the default sequence or DRTR service configuration, you 
will receive an error message. You must remove the host/ group from the 
sequence or service first, then delete. 
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ICP is a communication protocol for caches. It allows a cache (not necessarily a 
ProxySG) to query other caches for an object, without actually requesting the 
object. By using ICP, the cache can determine if the object is available from a 
neighboring cache, and which cache provides the fastest response. 



Note: The ProxySG (assuming ICP is configured) does ICP queries only if no 
forwarding host or SOCKS gateway is identified as an upstream target. If ICP is 
used by the appliance, it prompts other cache devices for the item, and upon a 
positive response re-directs the upstream request to that cache device instead of 
the content origin server. 



Only use ICP if you have ICP hosts available or to have the ProxySG support 
requests from other ICP hosts. 

By default, the ICP protocol requires the requesting host to wait up to two 
seconds for all ICP hosts to respond to the request for an object (the time is 
configurable). 

If the ICP service is configured and running, the service is used if no 
forwarding or SOCKS gateway target was specified. In other words, the policy 
rule icp (yes ) is the default, assuming that the ICP service is available. You can 
disable ICP with the policy rule icp (no) to control ICP queries for requests. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ "About ICP Hierarchy" on page 153 

□ "Using ICP Configuration Directives to Create an Installable List" on page 
154 

□ "Naming the IP Hosts" on page 155 

□ "Restricting Access" on page 156 

□ "Connecting to Other ICP Hosts" on page 157 

□ "Creating an ICP Installable List" on page 158 

□ "Enabling ICP" on page 159 

About ICP Hierarchy 

An ICP hierarchy is comprised of a group of caches, with defined parent and 
sibling relationships. A cache parent is one that can return the object if it is in 
the cache, or request the object from the source on behalf of the requester if the 
object is not in the cache. A cache sibling is a device that can only return the 
object if it is in the cache. One cache acting as a parent can also act as a sibling to 
other cache devices. 
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□ When an object is not cached, the cache device sends an ICP query to its 
neighbors (parents and siblings) to see if any of its peers holds the object. 

□ Each neighbor that holds the requested object returns an icp hit reply 

□ Each neighbor that does not hold the object returns an icp miss reply 

Based on the responses, the cache can determine where to request the object: from 
one of its neighbors or from the source. If an icp hit reply is received, the request 
is sent to the host that returned the first reply. If no icp hit reply is received, the 
request is forwarded to the first parent that replied. If no parents respond or are 
configured, the request is made directly to the source. 

Using ICP Configuration Directives to Create an Installable List 

To configure ICP you must create an installable list and load it on the ProxySG. 
The ICP protocol contains a number of directives, commands used to create a list 
that can be installed on the ProxySG. 

For information on installing the file itself, see "Creating an ICP Installable List" 
on page 158. 

The ICP configuration includes directives that: 

□ Name the ICP hosts 

□ Restrict ICP access to only these hosts 
Available directives are listed in Table 9-1. 



Table 9-1 ICP Directives 



Directive 


Meaning 


Where used 


icp host 


The icp host directive describes cache peers in 
the hierarchy. There should be one entry for each 
ProxySG you want to use. 


Names the ICP hosts. See 
"Naming the IP Hosts" on 
page 155. 


icp access domain 


The icp access domain directive is used to 
control which ICP queries are accepted. The 
icp access domain directive requires a reverse 
DNS lookup of each ICP query to validate the IP 
address. 


Restricts access. See 
"Restricting Access" on 
page 156. 


icp access ip 


The icp access ip directive works like the 
icp access domain command, except that you 
can specify an IP address and subnet mask rather 
than a domain. 


Restricts access. 

See "Restricting Access" on 
page 156. 


icp port 


The icp_port directive sets the port the ProxySG 
uses to listen for ICP requests. The default port is 
3130. If you set the port to 0, ICP is disabled. 


Connects to other ICP 
hosts. See "Connecting to 
Other ICP Hosts" on page 
157. 
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Table 9-1 ICP Directives (Continued) 



Directive 


Meaning 


Where used 


neighbor timeout 


The neighbor timeout directive sets the number 
of seconds the ProxySG waits for ICP replies. 
When the cache device sends an ICP request, it 
waits for all hosts to reply or for the 
neighbor timeout to expire. The default timeout 
is two seconds. 


Connects to other ICP 
hosts. See "Connecting to 
Other ICP Hosts" on page 
157. 


icp failcount 


The icp failcount directive sets the number of 
consecutive failures the cache device can receive 
before considering the ICP host as failed. By 
default, the ICP failure count is set to 20. Each 
time a request fails, the failure count is 
incremented. When a request succeeds, the failure 
count is reset to zero. 


Connects to other ICP 
hosts. See "Connecting to 
Other ICP Hosts" on page 
157. 


http failcount 


The http failcount directive sets the number of 
consecutive failures the cache device can receive 
before considering the HTTP host as failed. By 
default, the HTTP failure count is set to five. The 
failure count increments each time a request fails. 
When a request succeeds, the failure count is reset 
to zero. When an HTTP host fails, the cache device 
waits five minutes before attempting to use it 
again as a forwarding target. If the next request 
fails, the cache device continues to wait five 
minutes between attempts until the cache 
becomes available. 


Connects to other ICP 
hosts. See "Connecting to 
Other ICP Hosts" on page 
157. 


host fail notify 


The host fail notify directive tells the cache 
device to send event notification e-mail when a 
connect fails persistently. 


Connects to other ICP 
hosts. See "Connecting to 
Other ICP Hosts" on page 
157. 


host recover 
notify 


The host recover notify directive tells the 
cache device to send event notification e-mail 
when a failed host recovers. 


Connects to other ICP 
hosts. See "Connecting to 
Other ICP Hosts" on page 
157. 



Naming the IP Hosts 

The icp host directive describes peers in the hierarchy. One entry is required for 
each ProxySG appliance you want to use. 

icp_host hostname peertype HTTPport ICPport [default I backup I 
feeder] 

Table 9-2 ICP host Directive 



Command 


Suboptions 


Description 


hostname 




The host name of the ProxySG. 
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Table 9-2 ICP host Directive 



Command 


Suboptions 


Description 


peertype 


{parent | 
sibling} 


Relationship of the appliance to the cache device you are configuring. 


HTTPport 




TCP port where the appliance accepts HTTP requests. The common 
HTTP port is 80 or 8080. 


ICPport 




UDP port where the appliance accepts ICP requests. The common ICP 
port is 3130. 


default 




If specified, designates a ProxySG host parent to be the default ICP 
parent. If no ICP reply is received, all requests are forwarded to the 
default parent. 


backup 




If specified, designates the cache device host parent to be the backup 
default ICP parent. If the default parent is not available, the cache 
device uses the backup default parent. 


feeder 




If specified, designates the ProxySG host sibling as a feeder-type host, 
using ICP request loops to populate the appliance. 



The following are sample icp host directives that can be entered into the ICP 
configuration: 



; Define 
icp_host 
icp^host 
icp_host 
icp^host 
icp_host 



ICP parent and si 
cml . bluecoat . com 
cm2 .bluecoat . com 
cm3 .bluecoat . com 
cm4 .bluecoat . com 
cm5 .bluecoat . com 



bling hosts. 

parent 8080 3130 default 
sibling 8080 3130 
sibling 8080 3130 
sibling 8080 3130 
parent 8080 3130 



Restricting Access 

You can restrict access to ProxySG appliances acting as caches by other ICP hosts 
using the icp access domain and icp access ip directives. By default, when ICP 
is configured, all ICP hosts are allowed access. You should deny access to all 
domains other than the ICP hosts you want to use. 

icp_access_domain Directive 

The icp access domain directive defines which hosts can request objects from the 
Web cache using ICP. The default action is to allow all requests. When you use 
icp_acces s_doma i n, each ICP query requires a reverse DNS lookup to validate the 
IP address. Depending on the number of ICP requests, these lookups can 
consume ProxySG resources. 

icp_access_domain {allow | deny} domain 



Table 9-3 ICP Access Domain Directive 



Directive Option 


Description 


allow | deny 


Allows or denies ICP queries from neighbors that match the 
domain specification. 
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Table 9-3 ICP Access Domain Directive 



Directive Option 


Description 


domain 


The domain to match. All ICP queries from neighbors that match 
the specified domain are handled by the host. The special domain 
of nil defines the default action when there is no domain match. 



The following are sample icp access domain directives to be entered into the ICP 
configuration: 

; allow ICP access to this Blue Coat Systems SG Appliance from the 
; bluecoat.com domain 

icp_access_domain allow bluecoat.com 
icp_access_domain deny all 

; the deny all option should always be specified to deny all other 
; domains 



icp_access_ip Directive 

The icp access ip directive works like the icp access domain command, except 
that you can specify an IP address and subnet mask rather than a domain. The 
following describes the parameters for the icp access ip command: 

icp_access_ip {allow | deny} subnet mask 



Table 9-4 ICAP Access IP Directive 



Directive Option 


Description 


allow | deny 


Allow or deny ICP queries from neighbors that match the 
address specification. 


address/subnet mask 


The address and subnet mask to match. All ICP queries that 
match the specified address are handled by the ICP host. The 
special address of 0 . 0 . 0 . 0 defines the default action when 
there is no address match. 



The following are samp 
configuration: 



e icp_access_ip 



directives to be entered into the ICP 



; allow ICP access to this Blue Coat Systems SG Appliance from the 
local subnet 

icp_access_ip allow 192.168.10.0/255.255.255.0 
icp_access_ip deny 10.25.36.47 

; the deny all option should always be specified to deny all other 
domains 



Connecting to Other ICP Hosts 

In addition to the ICP directives described in the sections above, you can specify 
the following directives in the ICP configuration: 

icp_p° r t 0 
neighbor_timeout 2 
icp_failcount 20 
http_f ailcount 5 
host_fail_notify on 
host_recover_notif y on 
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Table 9-5 Connecting to Other ICP Hosts 



Directive 


Description 


icp port 


The default port is 3130. If you set the port to 0, ICP is disabled. 


neighbor timeout 


When the cache device sends an ICP request, it waits for all 
hosts to reply or for the neighbor timeout to expire. The 
default timeout is two seconds. 


http failcount 


By default, the HTTP failure count is set to five. The failure 
count increments each time a request fails. When a request 
succeeds, the failure count resets to zero. When an HTTP host 
fails, the cache device waits five minutes before attempting to 
use it again as a forwarding target. 


icp failcount 


By default, the ICP failure count is set to 20. Each time a request 
fails, the failure count is incremented. When a request succeeds, 
the failure count is reset to zero. 


host fail notify 


on tells the cache to send event notification e-mail when a 
connect fails persistently; off disables this setting. 


host recover 
notify 


on tells the cache to send event notification e-mail when a failed 
host recovers; off disables this setting. 



Creating an ICP Installable List 

You can create the ICP installable list using one of the following methods: 

□ Text Editor, which allows you to enter directives (or copy and paste the 
contents of an already-created file) directly onto the ProxySG. 

□ Local file, installed on your system; the ProxySG can browse to the file and 
install it. 

□ A remote URL, where you place an already-created file on an FTP or HTTP 
server to be downloaded to the appliance. 

□ The CLI inline command. 

When the ICP installable list is created and installed, it overwrites any ICP 
settings on the ProxySG. 

To create an ICP installable list: 

1. Select Configuration > Forwarding > ICP. 

2. From the drop-down list, select the method you want to use to install the ICP 
configuration; then click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the 
configuration is located. To view the file before installing it, click View. 
Click Install. Examine the installation status that displays; click OK. 
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• Local File: 

Click Browse to bring up the Local File Browse window. Browse for the file 
on the local system. Click Install. When the installation is complete, a 
results window opens. View the results, close the window, click Close. 

• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the 
installation is complete, a results window opens. View the results, close 
the window, click Close. 

3. Click Apply. 

Note: You can create ICP settings using the CLI inline commands. 

For more information on using inline commands, refer to Volume 11: Command 
Line Interface Reference. 



Enabling ICP 

Before ICP can be used in the ProxySG environment: 

□ ICP must be running 

□ At least one forwarding host must be configured 

ICP can be enabled or disabled through the policy rule icp .The default is 

icp (yes) . You can disable ICP with the policy rule icp (no) to control ICP queries 

for requests. 
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This chapter discusses the Routing Information Protocol (RIP), which is 
designed to select the fastest route to a destination. RIP support is built into the 
ProxySG appliance, and is configured by created and installing an RIP 
configuration text file onto the device. 

The Blue Coat RIP implementation also supports advertising default gateways. 
Default routes added by RIP are treated the same as the static default routes; 
that is, the default route load balancing schemes apply to the default routes 
from RIP as well. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ "Installing RIP Configuration Files" on page 161 

□ "Configuring Advertising Default Routes" on page 163 

□ "RIP Commands" on page 163 

□ "RIP Parameters" on page 164 

□ "ProxySG-Specific RIP Parameters" on page 165 

□ "Using Passwords with RIP" on page 166 

Installing RIP Configuration Files 

No RIP configuration file is shipped with the appliance. For commands that 
can be entered into the RIP configuration file, see "RIP Commands" on page 
163. 

After creating an RIP configuration file, install it using one of the following 
methods: 

□ Using the Text Editor, which allows you to enter settings (or copy and paste 
the contents of an already-created file) directly onto the appliance. 

□ Creating a local file on your local system; the ProxySG can browse to the file 
and install it. 

□ Using a remote URL, where you place an already-created file on an FTP or 
HTTP server to be downloaded to the ProxySG. 

□ Using the CLI inline rip-settings command, which allows you to paste 
the RIP settings into the CLI. 

□ Using the CLI rip commands, which require that you place an already- 
created file on an FTP or HTTP server and enter the URL into the CLI. You 
can also enable or disable RIP with these commands. 
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To install an RIP configuration file: 



Note: When entering RIP settings that affect current settings (for example, when 
switching from ripvl to ripv2), disable RIP before you change the settings; re- 
enable RIP when you have finished. 



1. Select Configuration > Network > Routing > RIP. 

2. To display the current RIP settings, routes, or source, click one or all of the 
View RIP buttons. 

3. In the Install RIP Setting from drop-down list, select the method used to install 
the routing table; click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the routing 
table is located. To view the file before installing it, click View. Click Install. 
To view the installation results, click Results; close the window when you 
are finished. Click OK. 

• Local Lile: 

Click Browse to display the Local Lile Browse window. Browse for the file 
on the local system. Open it and click Install. When the installation is 
complete, a results window opens. View the results and close the window. 

• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the 
installation is complete, a results window opens. View the results, close 
the window, and click OK. 

4. Click Apply. 

5. Select Enable RIP. 

6. Click Apply. 

Related CLI Syntax to Configure RIP 

SGOS# (config) rip {disable | enable} 

□ To enter a path to a remote URL where you have placed an already-created 
RIP configuration file, enter the following commands at the (config) 
command prompt: 

SGOS# (config) rip path url 
SGOS# (config) load rip-settings 

□ To paste an RIP configuration directly into the CLI, enter the following 
command at the (config) command prompt: 

SGOS# (config) inline rip-settings end-of-file_marker 
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Configuring Advertising Default Routes 

Default routes advertisements are treated the same as the static default routes; 
that is, the default route load balancing schemes also apply to the default routes 
from RIP. 

By default, RIP ignores the default routes advertisement. You can change the 
default from disable to enable and set the preference group and weight through 
the CLI only. 

To enable and configure advertising default gateway routes: 

1. At the (config) command prompt: 

SGOS# (config) rip default- route enable 

SGOS# (config) rip default- route group group_number 
SGOS# (config) rip default- route weight weight_number 

Where group_number defaults to i, and weight_number defaults to 100, the same 
as the static default route set by the ip-defauit-gateway command. 

2. (Optional) To view the default advertising routes, enter: 

SGOS# (config) show rip default-route 

RIP default route settings: 

Enabled: Yes 

Preference group: 3 

Weight: 30 

RIP Commands 

You can place any of the commands below into a Routing Information Protocol 
(RIP) configuration text file. You cannot edit a RIP file through the command line, 
but you can overwrite a RIP file using the inline rip-settings command. 

After the file is complete, place it on an HTTP or FTP server accessible to the 
ProxySG and download it. 



Note: RIP parameters are accepted in the order that they are entered. If a RIP 
parameter is added, it is appended to the default RIP parameters. If a subsequent 
parameter conflicts with a previous parameter, the most recent one is used. 



net 



net Nname [ /mask] gateway Gname metric Value {passive I active I 
external } 



Table 10-1 net Commands 



Parameters 


Description 


Nname 


Name of the destination network. It can be a symbolic 
network name, or an Internet address specified in dot 
notation. 


/mask 


Optional number between 1 and 32 indicating the netmask 
associated with Nname. 
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Table 10-1 net Commands (Continued) 



Parameters 


Description 


Gname 


Name or address of the gateway to which RIP responses 
should be forwarded. 


Value 


The hop count to the destination host or network. A net 
Nname/32 specification is equivalent to the host Hname 
command. 


passive I active | 
external 


Specifies whether the gateway is treated as passive or active, 
or whether the gateway is external to the scope of the RIP 
protocol. 



host 



host Hname gateway Gname metric Value {passive | active | external} 



Table 10-2 host Commands 



Parameters 


Description 


Hname 


Name of the destination network. It can be a symbolic 
network name, or an Internet address specified in dot 
notation. 


Gname 


Name or address of the gateway to which RIP responses 
should be forwarded. It can be a symbolic network name, or 
an Internet address specified in dot notation. 


Value 


The hop count to the destination host or network. A net 
Nname/32 specification is equivalent to the host Hname 
command. 


passive | active | 
external 


Specifies whether the gateway is treated as passive or active, 
or whether the gateway is external to the scope of the RIP 
protocol. 



RIP Parameters 

Lines that do not start with net or host commands must consist of one or more of 
the following parameter settings, separated by commas or blank spaces: 



Table 10-3 RIP Parameters 



Parameters 


Description 


if= [0 | 1 | 2 | 3] 


Specifies that the other parameters on the line apply to the interface 
numbered 0,1,2, or 3 in SGOS terms. 


passwd=XXX 


Specifies an RIPv2 password included on all RIPv2 responses sent and 
checked on all RIPv2 responses received. The password must not contain any 
blanks, tab characters, commas or '#' characters. 


no ag 


Turns off aggregation of subnets in RIPvl and RIPv2 responses. 
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Table 10-3 RIP Parameters (Continued) 



Parameters 


Description 


no super ag 


Turns off aggregation of networks into supernets in RIPv2 responses. 


passive 


Marks the interface to not be advertised in updates sent through other 
interfaces, and turns off all RIP and router discovery through the interface. 


no rip 


Disables all RIP processing on the specified interface. 


no ripvl in 


Causes RIPvl received responses to be ignored. 


no ripv2 in 


Causes RIPv2 received responses to be ignored. 


ripv2 out 


Turns off RiPvl output and causes RiPv2 advertisements to be multicast 
when possible. 


r ipv2 


Is equivalent to no ripvl in and no ripvl out. This parameter is set by 
default. 


no rdisc 


Disables the Internet Router Discovery Protocol. This parameter is set by 
default. 


no solicit 


Disables the transmission of Router Discovery Solicitations. 


send solicit 


Specifies that Router Discovery solicitations should be sent, even on point-to- 
point links, which by default only listen to Router Discovery messages. 


no rdisc adv 


Disables the transmission of Router Discovery Advertisements. 


rdisc adv 


Specifies that Router Discovery Advertisements should be sent, even on 
point-to-point links, which by default only listen to Router Discovery 
messages. 


beast rdisc 


Specifies that Router Discovery packets should be broadcast instead of 
multicast. 


rdisc pref=N 


Sets the preference in Router Discovery Advertisements to the integer N. 


rdisc interval=N 


Sets the nominal interval with which Router Discovery Advertisements are 
transmitted to N seconds and their lifetime to 3*N. 


trust gateway=rname 


Causes RIP packets from that router and other routers named in other 
trust_gateway keywords to be accept, and packets from other routers to be 
ignored. 


redirect ok 


Causes RIP to allow ICMP Redirect messages when the system is acting as a 
router and forwarding packets. Otherwise, ICMP Redirect messages are 
overridden. 



ProxySG-Specific RIP Parameters 

The following RIP parameters are unique to ProxySG configurations: 
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Table 10-4 ProxySG-Specific RIP Parameters 



Parameters 


Description 


supply routing info 


-s option: 


-or- 


Supplying this option forces routers to supply routing 


advertise routes 


information whether it is acting as an Internetwork router 




or not. This is the default if multiple network interfaces are 
present or if a point-to-point link is in use. 

-g option: 

This flag is used on Internetwork routers to offer a route to 
the 'default' destination. This is typically used on a 
gateway to the Internet, or on a gateway that uses another 
routing protocol whose routes are not reported to other 
local routers. 

-h option: 

Suppress extra host routes advertise host route 

-m option: 

Advertise host route on multi-homed hosts 
-A option: 

Ignore_authentication / / 


no supply 


-q option: 


routing info 


opposite of -s. 


no rip out 


Disables the transmission of all RIP packets. This setting is 
the default. 


no ripvl out 


Disables the transmission of RlPvl packets. 


no ripv2 out 


Disables the transmission of RlPv2 packets. 


rip out 


Enables the transmission of RlPvl packets. 


ripvl out 


Enables the transmission of RlPvl packets. 


rdisc 


Enables the transmission of Router Discovery 
Advertisements. 


ripvl 


Causes RlPvl packets to be sent. 


ripvl in 


Causes RlPvl received responses to be handled. 



Using Passwords with RIP 

The first password specified for an interface is used for output. All passwords 
pertaining to an interface are accepted on input. For example, with the following 
settings: 

if=0 passwd=aaa 
if=l passwd=bbb 
passwd=ccc 

Interface 0 accepts passwords aaa and ccc, and transmits using password aaa. 
Interface 1 accepts passwords bbb and ccc, and transmits using password bbb. The 
other interfaces accept and transmit the password ccc. 
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This chapter discusses how you can configure the SGOS software to monitor 
RADIUS accounting messages and to maintain a session table based on the 
information in these messages. The session table can then be used for logging 
or authentication. 

You can also, optionally, configure multiple appliances to act as a session 
monitor cluster. The session table is then replicated to all members of the cluster. 

Once configured and enabled, the session monitor maintains a session table 
that records which sessions are currently active and the user identity for each 
session. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ "Configuring the Session Monitor" on page 167 

□ "Creating the CPL" on page 170 

Configuring the Session Monitor 

Three steps are required to configure the session monitor: 

□ Configure the RADIUS accounting protocol parameters for the session 
monitor. 

□ (Optional) Configure the session monitor cluster. 

□ Configure the session monitor parameters. 

Configuring the RADIUS Accounting Protocol Parameters 

The configuration commands to create the RADIUS accounting protocol 
parameters can only be done through the CLI. If you are using session-monitor 
clustering, the commands must be invoked on each system in an already- 
existing failover group. (For information on configuring a failover group, see 
Chapter 7: "Configuring Failover" on page 125.) 

To configure the RADIUS accounting protocol parameters: 

□ To enter configuration mode: 

SGOS# (config) session-monitor 

□ The following subcommands are available: 

SGOS# (config session-monitor) radius acct-listen-port port_number 
SGOS# (config session-monitor) radius authentication {enable | 
disable } 

SGOS# (config session-monitor) radius encrypted-shared-secret 

encrypted__secret 
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SGOS# (config session-monitor) radius no encrypted-shared-secret 
SGOS# (config session-monitor) radius response {enable | disable} 

SGOS# (config session-monitor) radius shared-secret plaintextsecret 



Table 11-1 Session Monitor Accounting Command Descriptions 



Command 


Option 


Description 


radius acct-listen-port 


port number 


The port number where the ProxySG listens for 
accounting messages 


radius authentication 


enable | disable 


Enable or disable (the default) the 
authentication of RADIUS messages using the 
shared secret. The shared secret must be 
configured before authentication is enabled. 


radius encrypted-shared- 
secret 


encrypted shared 
secret 


Specify the shared secret (in encrypted form) 
used for RADIUS protocol authentication. The 
secret is decrypted using the configuration- 
passwords-key. 


radius no shared-secret 




Clears the shared secret used for RADIUS 
protocol authentication. 


radius response 


enable | disable 


Enable (the default) or disable generation of 
RADIUS responses. 


radius shared-secret 


plaintext secret 


Specify the shared secret used for RAIDUS 
protocol in plaintext. 



Configuring a Session Monitor Cluster 

Configuring a session monitor cluster is optional. When a session monitor cluster 
is enabled, the session table is replicated to all members of the cluster. The cluster 
members are the ProxySG appliances that are configured as part of the failover 
group referenced in the session monitor cluster configuration. The failover group 
must be configured before the session monitor cluster. (For information on 
configuring a failover group, see Chapter 7: "Configuring Failover" on page 125.) 

To replicate the session table to all the members of a failover group, you can use 
the following commands. 



Note: When using a session monitor cluster, the RADIUS client must be 
configured to send the RADIUS accounting messages to the failover group's 
virtual IP address. 



Proxy traffic can be routed to any of the machines in the cluster. 



Note: Each member of the failover group must configured with the cluster 
commands to maintain the session table for RADIUS accounting messages. 



To configure session monitor cluster parameters: 

SGOS# (config) session-monitor 
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□ The following subcommands are available: 

SGOS# (config session-monitor) cluster {enable | disable} 

SGOS# (config session-monitor) cluster group-address IP_address 
SGOS# (config session-monitor) cluster port port_number 
SGOS# (config session-monitor) cluster grace-period seconds 
SGOS# (config session-monitor) cluster synchronization-delay seconds 



Table 11-2 Session Monitor Cluster Command Descriptions 



Command 


Option 


Description 


cluster 


enable I 
disable 


Enable or disable (the default) clustering on a failover 
group. The group address must be set before the 
cluster can be enabled. 


cluster group-address 
I no group-address 


IP address 


Set or clear (the default) the failover group IP address. 
This must be an existing failover group address. 


cluster port 


port number 


Set the TCP/IP port for the session replication control. 
The default is 55555. 


cluster 

synchronization-delay 


seconds 


Set the maximum time to wait for session table 
synchronization. The default is zero; the range is from 
0 to 2 A 31 -1 seconds. During this time evaluation of 
$ (session, username) is delayed, so proxy traffic 
might also be delayed. 


cluster grace-period 


seconds 


Set the time to keep session transactions in memory 
while waiting for slave logins. This can be set to allow 
session table synchronization to occur after the 
synchronization-delay has expired. The default is 30 
seconds; the range is 0 to 2 A 31-1 seconds. 



Configuring the Session Monitor 

The session monitor commands set up session monitoring behavior. If using 
session-monitor clustering, these commands must be invoked on all systems in 
the failover group. 

To configure the session monitor: 

1. At the (config) prompt: 

SGOS# (config) session-monitor 

SGOS# (config session-monitor) disable | enable 
SGOS# (config session-monitor) max-entries integer 
SGOS# (config session-monitor) timeout minutes 
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Table 11-3 Session Monitor Configuration Command Descriptions 



Command 


Option 


Description 


enable | disable 




Enable or disable (the default) session monitoring 


max entries 


integer 


The maximum number of entries in the session 
table. The default is 500, 000; the range is from 1 
to 2, 000, 000. If the table reaches the maximum, 
additional START messages are ignored. 


timeout 


minutes 


The amount of time before a session table entry 
assumes a STOP message has been sent. The 
default is 120 minutes; the range is from 0 to 
65535 minutes. Zero indicates no timeout. 



2. (Optional) To view the session-monitor configuration, you can either use the 

session-monitor view command or the COnfig show session-monitor 

command. 

SGOS# (config) show session-monitor 

General : 

Status: enabled 

Entry timeout: 120 minutes 

Maximum entries: 500000 

Cluster support: enabled 

Cluster port: 55555 

Cluster group address: 10.9.17.159 

Synchronization delay: 0 

Synchronization grace period: 30 

Accounting protocol : radius 

Radius accounting: 

Listen ports: 

Accounting: 1813 
Responses : Enabled 
Authentication: Enabled 
Shared secret: ************ 

Creating the CPL 

Be aware that the examples below are just part of a comprehensive authentication 
policy. By themselves, they are not adequate. 



Note: Refer to Volume 10: Content Policy Language Guide for details about CPL and 
how transactions trigger the evaluation of policy file layers. 



□ In this example, the ProxySG is using the session table maintained by the 
session monitor for authentication. 

<proxy> 

allow authenticate (session) 

where session is a policy substitution realm that uses $ (session, username) in 
building the username. (For information on creating a Policy Substitution 
realm, refer to Volume 4: Securing the Blue Coat ProxySG Appliance.) 
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Notes 

□ The session table is stored entirely in memory. The amount of memory needed 
is roughly 40MB for 500,000 users. 

□ The session table is kept in memory. If the system goes down, the contents of 
the session table are lost. However, if the system is a member of a failover 
cluster, the current contents of the session table can be obtained from another 
machine in the cluster. The only situation in which the session table is entirely 
lost is if all machines in the cluster go down at the same time. 

□ The session replication protocol replicates session information only; 
configuration information is not exchanged. That means that each ProxySG 
must be properly configured for session monitoring. 

□ The session replication protocol is not secured. The failover group should be 
on a physically secure network to communicate with each other. 

□ The session monitor requires sufficient memory and at least lOOMb-per- 
second network links among the cluster to manage large numbers of active 
sessions. 

□ The username in the session table is obtained from the Calling-Station-ID 
attribute in the RADIUS accounting message and can be a maximum of 19 
bytes. 



171 



Volume 5: Advanced Networking 



172 



Chapter 12: Accelerating and Controlling Micro-Branch and 
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This chapter describes the Blue Coat ProxyClient solution, which provides 
security to mobile users and enables systems that do not reside behind a 
gateway Blue Coat ProxySG to achieve accelerated performance and ensure 
users abide by company Web usage policies. 

This chapter discusses the following topics: 

□ Section A: "ProxyClient Concepts" on page 174 

□ Section B: "Configuring a ProxySG as the Client Manager" on page 205 

□ Section C: "Configuring the ProxyClient" on page 216 

□ Section D: "Distributing the ProxyClient Software" on page 266 

□ Section E: "About the ProxyClient Application" on page 288 

□ Section F: "Monitoring ProxyClient Performance" on page 293 

□ Section G: "About the ProxyClient System Footprint" on page 298 

□ Section H: "ProxyClient Troubleshooting" on page 304 
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Section A: ProxyClient Concepts 

Section A: ProxyClient Concepts 

Before configuring the ProxyClient, Blue Coat recommends that you understand 
the conceptual information discussed in this section. 



Note: This section assumes that you are familiar with the Blue Coat 
Application Delivery Network (ADN) concepts and features, as described in 
Chapter 2: "Configuring an Application Delivery Network" on page 17. 



This section includes the following topics: 

□ "Why Deploy ProxyClient?" 

□ "Terminology" on page 175 

□ "About Blue Coat in the Network" on page 177 

□ "About the Roles of ProxySG Appliances With the ProxyClient" on page 178 

□ "About the Role of the ProxyClient" on page 179 

□ "About ProxyClient Licensing" on page 181 

□ "About Location Awareness" on page 182 

□ "About ADN Feature Support in ProxyClient" on page 192 

□ "About ProxyClient Web Filtering" on page 196 

□ "ProxyClient Security Disclaimers" on page 204 

Why Deploy ProxyClient? 

As mobile technology efficiency has advanced, so has the ability for enterprises 
and other organizations to mobilize their workforce and allow access to remote 
systems. Employees who are often in the field, at home, or in small offices — 
including those who log into the corporate network through a Virtual Private 
Network (VPN) connection — require the same performance that is achieved when 
in the corporate network environment. 

Likewise, corporations seek to extend the same security, policy control, and 
tracking abilities that are available in the corporate network. Blue Coat designed 
the ProxyClient solution to provide accelerated application delivery and Web 
filtering in the following scenarios: 

□ For employees using laptops and who work from both the office and the field. 
These users enjoy accelerated network performance while on the corporate 
network, but lose that performance when they must, from a remote location, 
connect to the enterprise network using VPN. 

□ For users in micro-branches, or offices with a very small number of users, 
where it might not be cost-justifiable to deploy even the smallest Blue Coat 
ProxySG acceleration gateway appliance. 

In both of these scenarios, the ProxyClient maintains user productivity levels by 
providing enterprise-grade performance, while also ensuring that the corporate 
Web usage policies are maintained on company-owned systems in the field (only 
users with administrator privileges can remove or disable the ProxyClient). 
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Section A: ProxyClient Concepts 

Terminology 

This chapter commonly uses to the following terms: 

□ ProxyClient 

Downloaded and installed on user systems, the ProxyClient provides 
increased network performance and Web filtering when the connection is 
from a network that is not fronted by a Blue Coat ProxySG. Users are afforded 
some configuration and monitoring abilities. 

□ ADN Manager 

Every ADN network must have a ProxySG designated as the ADN Manager, 
which is responsible for publishing the routing table to ProxyClients (and to 
other ProxySG ADN peers). 

You can optionally designate another ProxySG appliance as the backup 
manager. This appliance takes over the duty of providing routing information 
to ProxyClients in the event the ADN manager becomes unavailable. 

□ Concentrator 

A ProxySG appliance that receives inbound ADN tunnels from the 
ProxyClient (and other ProxySG appliances on the ADN network) and 
accelerates data center resources (such as file servers and Web applications). 

□ Branch ProxySG 

A ProxySG deployed near a branch office router (where branch office means a 
small or regional office). To retrieve client file and data requests from servers 
located in the corporate data center, the branch proxy connects to the ADN 
concentrators — which are advertised by the ADN manager or discovered 
transparently — in the data centers at the corporate location. 

If the branch location has servers, the branch peer also serves as a 
concentrator. A branch ProxySG can provide acceleration, Web filtering, or 
both for the branch office. 

□ Client Manager 

A Client Manager is a ProxySG (running a compatible version of SGOS) that 
provides the ProxyClient software to users, maintains the software and the 
client configuration of all clients in the ADN network. Commonly, the Client 
Manager appliance is deployed in the intranet behind the enterprise VPN 
gateway, with a router connection to the Internet. 

For details, including which SGOS versions are supported, see the 
ProxyClient Release Notes. 

□ Mobile user 

Employees who use laptops with ProxyClient installed and travel from 
corporate locations to other locations, such as customer sites, hotels, or home 
offices. Mobile users does not refer to users with hand-held devices. 
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□ Location awareness 

The ability of the ProxyClient to detect the presence of a network connection 
and enable or disable acceleration and Web filtering as determined by policy 
For example, you typically disable both ProxyClient acceleration and Web 
filtering in the office but enable them for mobile users. 

The ProxySG administrate determines the criteria that define locations and 
enables or disables acceleration and Web filtering for each location. 

□ Byte caching 

A specific form of compression that looks for repeated data patterns 
transmitted over the WAN. Byte caching plus other forms of compression 
(such as gzip) optimizes the data sent over the TCP tunnel. 

□ Common Internet File System (CIFS) optimization 

ProxyClient significantly enhances WAN file service delivery by 
implementing the following: 

• CIFS protocol optimization, which improves performance by 
consolidating data forwarded across the WAN. 

• Client object caching, which enables clients to get previously obtained 
data from the cache rather than from across the WAN. 

These terms are brief descriptions of ADN technology as they relate to 
ProxyClient. For more detailed information about the Blue Coat WAN optimization 
solution, see Chapter 2: "Configuring an Application Delivery Network". 
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About Blue Coat in the Network 

ProxyClient optimizes the enterprise network conduit between remote or micro- 
branch office systems and ProxySG appliances. Figure 12-1 provides a high-level, 
logical view of Blue Coat deployed in the network. 
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Figure 12-1 Blue Coat in the network 



Blue Coat does not provide strict guidelines for determining whether a remote 
location requires a local ProxySG. Generally, use a local ProxySG if the branch 
office has a data center (that is, file servers and so on) and to offload acceleration 
and Web filtering functions from the corporate ProxySGs to the branch. 

Blue Coat recommends considering a ProxyClient-only solution at a remote 
location if any of the following is true: 



□ The remote location is a mobile user whose location is constantly changing. 

□ The remote location is a home office. 



□ The remote location has a few users and therefore does not justify a local 
ProxySG appliance. 

In any of the proceeding locations, you might provide connectivity to the 
corporate network with VPN client software; however, that is not a requirement 
for using the ProxyClient. 
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Note: Refer to the ProxyClient Release Notes for the latest list of supported VPN 
technologies and operating systems. 



About the Roles of ProxySG Appliances With the ProxyClient 

One or more ProxySG appliances interact with ProxyClients in the following 
ways: 

□ ADN Manager and backup manager — As discussed in "Terminology" on page 
175, you must configure an ADN Manager and Blue Coat recommends you 
also configure a backup manager. 

□ Client Manager — The ProxySG that provides the management infrastructure 
to ProxyClients, including the following services: 

• Software for the client (initial deployment and updates) 

• Periodic verification of the Blue Coat Web Filter (BCWF) license and 
database (required to use BCWF) 

• Monitoring 

• Client configuration management (such as Web filtering policy) 



Note: The Client Manager can be any appliance in the ADN network, including a 
concentrator, the ADN manager, or a backup manager. For example, the Client 
Manager could also be the ADN manager, but that is not a requirement. 



□ Concentrator — A ProxySG that terminates ProxyClient ADN tunnels, and 
provides two-way compression and data forwarding to and from the 
appropriate server. A concentrator accelerates network traffic. 

□ Branch ProxySG — Depending on how it is configured, a branch ProxySG 
might provide acceleration and Web filtering for a branch office. 
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The following diagram illustrates a high-level network architecture involving 
ProxyClient. 
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Figure 12-2 High-level ProxyClient network diagram 



About the Role of the ProxyClient 

The ProxyClient software is made available either manually by user installation 
or is pre-installed by administrators. After it is installed and enabled, ProxyClient 
mimics a proxy appliance and processes requests. 

For example, if Web filtering is enabled and a user requests the URL 

www . amazon . com, a policy check occurs to verify that Shopping is an allowable 

category. 

If acceleration is enabled and a user requests a file transfer, ProxyClient applies 
the Blue Coat ADN compression capability to the CIFS protocol. The following 
diagram illustrates the high level decision order within ProxyClient (and assumes 
a valid base SGOS or trial license is installed). 
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WAN WAN 





FLOW 

1 — A mobile or micro-branch user initiates a request (either for files or for Web content by requesting a 
URL). 

2 — Assuming the license is valid and ProxyClient Web Filtering is enabled, ProxyClient performs a URL 
policy check (which involves more operations than depicted here). If the policy action is allow, the request 
continues to the acceleration check. 

3 — ProxyClient determines if ADN acceleration is enabled and applicable to this object. 

4a — If the ADN Manager is advertising ADN routes, the traffic routes to the proper ADN concentrator (that is, 
the ProxySG with the associated byte cache). 

4b — Requests are sent directly to the destination if there is no concentrator advertising a route to the 
destination; or when the only route is to the default Internet gateway and the destination is in the gateway’s 
exempt subnets list. 



Figure 12-3 ProxyClient data flow decision diagram 



180 





Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient) 



Section A: ProxyClient Concepts 



Note: More information about Web filtering is discussed in "About ProxyClient 
Web Filtering" on page 196. 



About ProxyClient Licensing 

There are two ProxyClient feature license components: 

□ The ProxyClient — Acceleration license enables the ProxyClient to accelerate 
ADN traffic, optimize file transfers using the CIFS protocol, and collect 
statistics to ProxyClient systems in your enterprise. 

The Client Manager license enables unlimited ProxyClient connections 
provided the SGOS base license is valid; however, concentrators have user 
limits. Each unique IP address counts as one user. 

Although the Client Manager license enables it to support unlimited users, 
you must size your ProxyClient deployment based on Client Manager 
scalability and concentrator user limits. 

□ The ProxyClient — Web Filtering license enables content filtering policy 
enforcement on ProxyClients. 



Important: 

• ProxyClient Web Filtering requires a valid Blue Coat Web Filter (BCWF) 
contract, with a valid BCWF database installed on the Client Manager 
(that is, the database must be updated at least once every 30 days). 

• Even if you have BCWF databases installed on other ProxySG appliances 
serving as forward proxies, you must download the BCWF database on 
the Client Manager. 



Ficenses are installed on the ProxySG and managed the same as other ProxySG 
features (as described in Volume 1: Getting Started). For ProxyClient, the feature 
licenses components enable the ProxySG to be a Client Manager. Any ProxySG 
still operating in the trial period can be a Client Manager as well. Client (user) 
systems do not require licenses to use the ProxyClient software. 
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Software and Hardware Requirements 

For information about software and hardware requirements, see the ProxyClient 
Release Notes. 

About Location Awareness 

This following sections discuss location awareness: 

□ "Overview of Location Awareness" 

□ "About Location Conditions" on page 183 

□ "About Condition Rulebase Ordering" on page 191 

Overview of Location Awareness 

Location azvareness enables administrators to enable or disable ProxyClient 
acceleration and Web filtering functionality based on the location from which the 
client connects. 

For example, the administrator should disable both acceleration and Web filtering 
for users in the office if ProxySG concentrators and proxies in the office perform 
those functions. Administrators should enable both acceleration and Web filtering 
for mobile users because there is no local ProxySG to perform those functions. (In 
general, enable the ProxyClient to perform functionality a local ProxySG does not 
perform.) 

Locations are defined by the ProxySG administrator using one or more the 
following location conditions (Configuration > ProxyClient > General > Locations): 

□ Source IP range, which is appropriate for situations (such as in the office) 
where you know the IP address range from which clients connect. 

□ DNS server IP address 

In some situations, the client's IP address might not be enough to uniquely 
define a location. If that is the case, DNS servers can be used as additional 
location conditions. 

□ Virtual network interface IP address, which should be used whenever clients 
connect to the corporate network using VPN software. 

VPN software typically creates a virtual network adapter (referred to as a 
virtual NIC ) that is assigned an IP address that is used when the client 
connects to the corporate network over VPN. 

A VPN gateway behind the firewall at the corporate data center provisions IP 
addresses and DNS server addresses to VPN clients. 



Note: Location conditions are logically ANDed together so choosing more 
than one location condition for a location is a good way to uniquely identify 
the location. 
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About Location Conditions 

This section discusses general guidelines to follow when setting up locations and 
provides an example: 

a "General Guidelines for Location Conditions" 

□ "Location Example" on page 184 

General Guidelines for Location Conditions 

In general, configure the ProxyClient to perform the features that a ProxySG does 
not perform (that is, either acceleration or Web filtering). When planning your 
ProxyClient deployment. Blue Coat recommends you take the following into 
account: 

□ Whether or not a ProxySG at the location performs acceleration or Web 
filtering 

□ Which two of the three available location conditions uniquely defines the 
location 

The following table shows how to use these guidelines in a sample four-location 
deployment: 



Location type 


How to apply the guidelines 


Mobile with no local 
ProxySG 


• Role of local ProxySG: There is none so the location 
should enable both ProxyClient acceleration and Web 
filtering. 

• Location conditions: To uniquely identify the 
location, choose Virtual NIC IP address and DNS 
server IP address. 


Headquarters with several 
local ProxySGs 


• Role of local ProxySGs: Perform both acceleration 
and Web filtering so the location should disable both 
features. 

• Location conditions: To uniquely identify the 
location, choose source IP address range and DNS 
server IP address. 


Branch office with no local 
ProxySG 


• Role of local ProxySG: There is none so the location 
should enable ProxyClient acceleration. However, if 
a branch ProxySG at headquarters performs Web 
filtering, you should disable Web filtering at the 
branch office. 

• Location conditions: To uniquely identify the 
location, choose source IP address range and DNS 
server IP address. 
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Location type 


How to apply the guidelines 


Branch office with a local 
ProxySG 


• Role of local ProxySG: If the local ProxySG performs 
both acceleration and Web filtering, the location 
should disable both. 

However, if the local ProxySG performs only 
acceleration, the location should disable ProxyClient 
acceleration and enable Web filtering. 

• Location conditions: To uniquely identify the 
location, choose source IP address range and DNS 
server IP address. 



Location Example 

Figure 12-4 shows a sample deployment with the following locations 

(Configuration > ProxyClient > General > Locations): 

□ A home office or mobile user that uses VPN to connect to the network 

□ Company headquarters 

□ Branch office with no local ProxySG; in this example, there is an IP address 
conflict to illustrate the importance of choosing more than one location 
condition 

□ Branch office with a local ProxySG that performs both acceleration and Web 
filtering 
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Figure 12-4 ProxyClient location awareness 

The following sections discuss Figure 12-4 in more detail: 

a "Home Office or Mobile Location" 

□ "Headquarters Location" on page 187 

□ "Branch Office Location with no ProxySG" on page 189 

□ "Branch Office With a Local ProxySG" on page 190 



Home Office or Mobile Location 

The home office user in Figure 12-4 connects to the corporate network using VPN. 
The network administrator configures a VPN gateway at headquarters to 
provision a pool of IP addresses and DNS server IP addresses for connecting to 
the corporate network. In this example, the IP address range is a subset of the 
headquarters IP address range. 

The user's VPN client software creates a virtual network adapter (also referred to 
as a virtual NIC) that has an IP address that is used when the user connects to the 
network. 

In Figure 12-4, the VPN IP address (also referred to as a virtual NIC IP) for the 
home office user is 10.3.0.5. 
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Setting up the home office or mobile location 

Keeping in mind the information discussed in "General Guidelines for Location 
Conditions” on page 183, the ProxySG administrator notes that in this location, 
there is no ProxySG to perform either acceleration or Web filtering. 

Therefore, to enable location awareness for home office or mobile users, the 
administrator sets up a location similar to the following: 
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The administrator chooses to match both of the following: 

□ A Virtual NIC IP range that matches the IP address range the VPN gateway at 
headquarters provisions. In this example, the Virtual NIC IP range is a subset 
of the headquarters IP address range. 

If your VPN hardware device manages its own IP addresses, or if you 
configure your VPN hardware to provision IP addresses in a particular range, 
make sure you enter the correct address range; otherwise, clients will not be 
identified at the correct location. 

□ To make sure the location is unique, the administrator adds the DNS servers' 
IP addresses. 

Enabling features for the home office location 

The ProxySG administrator enables both ProxyClient acceleration and Web 
filtering for this location because the user does not connect to a branch ProxySG. 



Note: Some VPN software does not create a virtual NIC with a separate IP 
address. Instead, the computer uses the IP address assigned to it by the user's 
home router or DHCP server. In that case, the administrator has the following 
options: 

• If this VPN solution enables the client computer to keep its IP address 
and DNS server, the same location works because even though the 
user's IP address might conflict with headquarters, the DNS server IP 
address will not. The user will be correctly identified in both locations. 

• Configure default policy actions, which are used when users do not 
match any location conditions. For more information, see "Configuring 
Default Actions" on page 230. 



Headquarters Location 

Users at headquarters connect to a ProxySG concentrator. Other ProxySG 
appliances at headquarters might perform other functions, such as Web filtering. 

Setting up the headquarters location 

Keeping in mind the information discussed in "General Guidelines for Location 
Conditions" on page 183, the ProxySG administrator notes that in this location, 
there are ProxySGs that perform both acceleration and Web filtering. 
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Therefore, to enable location awareness for headquarters users, the administrator 
sets up a location similar to the following. 




The administrator chooses to match both of the following: 

□ Source IP ranges because the administrator knows that users at headquarters 
are assigned IP addresses in this range. 

□ DNS servers because the administrator knows the DNS servers at 
headquarters. 

Together, source IP address ranges and DNS servers uniquely identify 
headquarters users. 

Enabling features for the headquarters location 

The ProxySG administrator disables both ProxyClient acceleration and Web 
filtering for this location because the user connects to a branch ProxySG at 
headquarters. Web filtering services are provided by a branch ProxySG; at 
headquarters, acceleration is usually not necessary because the client computer is 
on the same network as the servers. 
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Branch Office Location with no ProxySG 

In this example, assume that because of a recent acquisition, the branch office gets 
IP addresses assigned from the same network as headquarters (10.0.0.0 to 
10.5.255.255) This source address range poses a potential problem for the ProxySG 
administrator because it makes the two locations indistinguishable based on 
source IP address alone. 

Also, assume that the network is configured so traffic is sent from the branch 
through headquarters so a branch ProxySG at headquarters performs Web 
filtering. 

Keeping in mind the information discussed in "General Guidelines for Location 
Conditions" on page 183, the ProxySG administrator notes that in this location, 
there is no ProxySG to perform acceleration but there is a branch ProxySG at 
headquarters that performs Web filtering. 

Therefore, to enable location awareness for branch office users, the administrator 
sets up a location similar to the following: 




The administrator chooses to match both of the following: 

□ Source IP range because it partially identifies the branch office location. 

However, the problem is that a computer at the branch office might be 
identified as being at headquarters if only the source IP address range is used. 
If a computer at this branch office is identified as being at headquarters, 
neither acceleration nor Web filtering is enabled. 
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□ The branch's DNS server IP address because it is different from the DNS 
servers at headquarters. 

Because the administrator chooses to add the DNS server IP address to this 
location condition, both the headquarters and branch office locations are 
unique. Computers at each location will have the correct ProxyClient features 
applied to them. 

Enabling features for the branch office location (no ProxySG) 

The ProxySG administrator enables ProxyClient acceleration but disables Web 
filtering for this location. Acceleration is provided by the ProxyClient 
communicating with a concentrator at headquarters. 

Web filtering is provided by a branch ProxySG at headquarters so the 
administrator disables Web filtering at the branch office. 

Branch Office With a Local ProxySG 

To a ProxySG administrator, configuring a branch office that has a local ProxySG 
is similar to configuring the headquarters location. 

Keeping in mind the information discussed in "General Guidelines for Location 
Conditions" on page 183, the ProxySG administrator notes that in this location, 
there is a ProxySG to perform both acceleration and Web filtering. 

Therefore, to enable location awareness for branch office users, the administrator 
sets up a location similar to the following. 
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The administrator chooses to match both source IP address range and DNS server 
IP address because both are unique to this branch office. 

Enabling features for the branch office location (with Proxy SG) 

The ProxySG administrator disables both ProxyClient acceleration and Web 
filtering for this location because the ProxySG at the branch office provides these 
services. 

About Condition Rulebase Ordering 

The order in which locations display on the Configuration > ProxyClient > General > 
Locations tab page determine the order in which the rules are evaluated when 
users connect to the Client Manager. To avoid mismatches, order the rules from 
most to least restrictive. 

For example, suppose headquarters uses IP addresses in the range from 10.0.0.0 to 
10.255.255.255 but the VPN gateway located at headquarters has a pool of IP 
addresses in a subset of that range; for example, 10.3.1.1 to 10.3.1.255. Because the 
VPN gateway is used by home office or mobile users, the administrator wants to 
use different policy actions for headquarters and home office users. 

Users at the headquarters location should have ProxyClient acceleration and Web 
filtering disabled but users in a home office or mobile location should have both 
ProxyClient features enabled. 

To accomplish that, the administrator creates the two locations as follows. 



Location 


Conditions 


Headquarters 


• Source IP address range: 10.0.0.0 to 10.255.255.255 

• DNS server IP address: For example, 10.0.0.11 and 
10.0.0.12 


Home office or mobile 


• DNS server IP address: Same as headquarters 

• VNIC IP address range: 10.3.1.1 to 10.3.1.255 



To make sure the home office or mobile location is detected first, the administrator 
must order it in the rulebase before the headquarters location. An example 
follows. 



Client Manager I Client Software Locations 
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About ADN Feature Support in ProxyClient 

This section includes the following topics: 

□ "ADN Features" on page 192 

□ "About Internet Gateways" on page 193 

□ "About Reflecting the ProxyClient IP Address" on page 194 

ADN Features 

The ProxyClient supports the following ADN features: 

□ Byte caching — Byte caching is a compression mechanism where data tokens 
that represent larger blocks of repeated data are sent across the WAN. 

When one of these data tokens match tokens in the data dictionary cached on 
the ProxyClient computer, the entire block of data is passed to the application 
that requested it, resulting in reduced WAN bandwidth. For example, if you 
request a file using Internet Explorer and a data dictionary match is found, the 
data is sent to Internet Explorer. 

If no data dictionary match is found, the token and its corresponding byte 
values are added to the data dictionary cached on the ProxyClient computer. 

A data token is a few bytes in size; the corresponding block of data for a token 
is much larger. 

□ CIFS protocol (file sharing) optimization and CIFS object caching on the 
client — Regions of files that are read or written by the client are placed in the 
cache. Object caching applies to both read and write file activities. 



Note: You can set the maximum percentage of total disk space (as opposed to 
available disk space) the ProxyClient allocates to the byte cache and the CIFS 
cache. The ProxyClient always leaves at least 1GB of available disk space on 
the client computer. By default, the cache is located on the system root volume 
but the cache location can be changed as discussed in "Changing the Focation 
of the Cache" on page 324. 



□ Foad balancing and failover — The ProxyClient attempts three types of 
connections in the ADN network: the routing connection, the ADN tunneling 
connection, and a control connection. The routing connection obtains the routing 
table from the ADN Manager or backup Manager; the tunneling connection 
transfers data to the ADN network; and the control connection contains client 
identification information. 

The ProxyClient first attempts to connect to the primary ADN manager to get 
routing information; if the ADN Manager is not available, the client attempts 
to connect to the backup ADN Manager. If the backup ADN manager is also 
not available, the connection continues on (bypassed by ADN) because an 
ADN route is not provided. When either of the ADN Managers becomes 
available again, acceleration automatically resumes. 
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Client connections that do not go through a concentrator are not accelerated 
and remain unaccelerated as long as the connection is open (that is, until the 
connection is closed by the application). 

After a concentrator becomes available, new connections are accelerated. 

ADN peer affinity helps maintain fast application performance by persisting 
connections from a ProxyClient to a particular concentrator and therefore 
reusing the byte cache. After establishing a connection to an ADN peer, 
ProxyClient always attempts to connect to that peer; a connection to another 
peer occurs only when the initial peer becomes unavailable. 

□ Cache encryption — To maintain a high security level after content is retrieved 
over the network connection, ProxyClient supports the Microsoft Encrypted 
File System (EFS), which makes it extremely difficult for malicious users to 
hack into a user system's cache to retrieve company-sensitive files. 

No other user can access the data in the cache, even the system administrator. 

If ProxyClient is uninstalled, the EFS encrypted caches are also deleted. 



Note: EFS is supported only on the New Technology File System (NTFS) 
partitions, although Windows XP Home Edition supports NTFS, but not EFS. 
File Allocation Table (FAT) or FAT32 partitions do not support EFS and 
therefore, the cache is not encrypted on those partitions. 



About Internet Gateways 

The ProxyClient honors Internet Gateway settings. Network traffic that is not 
bound by ADN routing rules routes to the specified gateway unless an exception 
rule applies. 

There are some routes, such as those for local hosts, that are not required to go 
through the ADN Internet gateway. You can define these routes using the 
ProxySG Management Console (Configuration > ADN > Routing > Internet Gateway). 
ProxyClient uses this configuration. 
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About Reflecting the ProxyClient IP Address 

When the ProxyClient version 3.1 or later attempts to connect to a destination, it 
always requests the concentrator reflect its IP address. The concentrator can be 
configured to either reflect the client's IP address or to reject the reflection request. 

Concentrator client IP reflection configuration determines what IP address the 
concentrator advertises to the origin server as the source address — the 
concentrator's own address (referred to as use local IP) or as the ProxyClient 
computer's address (referred to as reflect the client IP). 



Note: For client IP reflection to work, the concentrator used by the ProxyClient 
should be deployed inline between the ProxyClient and the origin server. In 
other words, the return packets will have ProxyClient's IP address as the 
destination address and must be routed back through the same concentrator. 

If the origin server is able to connect directly back to the ProxyClient computer, 
the connection fails. This happens because the concentrator opens a different 
connection to the origin server than the one originally opened by the 
ProxyClient, so response packets going directly from the origin server to the 
ProxyClient will be rejected and the connection will fail. 

If the concentrator is deployed out of line, you can configure the concentrator 
to use local IP. 



For example, suppose the ProxyClient requests data from a server in the corporate 
data center. The ProxyClient request is accepted by a ProxySG concentrator, 
which sends the request to the server. When the concentrator sends the request, 
you can configure the following IP reflection options: 

□ Allow the request and reflect the client IP — The concentrator can present its own IP 

address as the source address. 

Select this option if your network is configured so that the origin server 
cannot reach a ProxyClient computer with an outside IP address; in other 
words, an IP address located outside the internal network. 

□ Allow the request but use a local IP — The concentrator can present the ProxyClient 
computer IP address as the source address. 

□ Reject the request — If the concentrator can be configured to deny client 
reflection, in which case one of the following occurs: 

• If the concentrator runs SGOS 5.3 or later, the concentrator presents its 
own IP address as the source address. This option is equivalent to Allow the 
request but use a local IP. 

• If the concentrator runs an SGOS version earlier than 5.3, the connection 
fails. 
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Note: If a ProxyClient connects to an ADN concentrator running an SGOS 
version earlier than 5.3, and that concentrator that is configured to reject client IP 
reflection requests, you must change the configuration. Otherwise, ProxyClients 
cannot connect to origin servers. 

Any of the following options can be used with the ProxyClient: 

• Management Console using the Configuration > ADN > Tunneling > Network 

tab page. 

Choose either of the following options (click Help for more information 
about the options): 

• Allow the request and reflect the client IP 

• Allow the request but use a local IP 

• Command line: 

• SGOS# (config adn tunnel) ref lect-client-ip allow 

• SGOS# (config adn tunnel) ref lect-client-ip use-local-ip 
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About ProxyClient Web Filtering 

Web filtering is required by many enterprises for security and compliance 
reasons. Network managers want the security of knowing users can be prevented 
from accessing Web sites with malicious content. Human Resources wants to 
prevent users from accessing offensive content or from losing productivity due to 
too much Web surfing. 

Blue Coat's Web filtering solution provides an answer for both concerns by 
providing robust filtering — both in the office and on the road. 

This section discusses Web filtering in the following sections: 

□ "Web Filtering Terminology" 

a "How Blue Coat Enforces Web Filtering for Remote and Micro-Branch Users" 
on page 197 

□ "Enabling or Disabling Web Filtering Based on Location" on page 198 

□ "About the BCWF Database and Categorization" on page 201 

□ "About Security With Guest User Scenarios" on page 204 

Web Filtering Terminology 

This section defines common terms used to discuss ProxyClient Web filtering. 

□ Blue Coat Web Filtering (BCWF) database 

A database that stores URLs and their corresponding categories. The database 
is maintained by Blue Coat and is accessible by service points located around 
the globe. 

To enable and use ProxyClient Web filtering, the BCWF database must be 
downloaded on the Client Manager and updated at least once every 30 days. 
(The database must be downloaded on the Client Manager for licensing 
purposes only; the ProxyClient does not use the BCWF database on the Client 
Manager.) 

The administrator chooses categories and policy actions for each category; 
these categories and actions are downloaded to the ProxyClient in its 
configuration file. For example, you can configure the ProxyClient to block 
any Web site that is categorized in the BCWF database as Pornography and to 
allow any Web site that is categorized as News/Media. 

□ Category 

Each known URL is classified into one or more categories. These categories 
are used by ProxySG administrators to determine whether a user who goes to 
a URL is allowed to access it, is blocked from accessing it, or is warned about 
accessing it. 

□ Service point 

Located around the world, service points obtain a URL categorization from 
the BCWF database. Anytime a ProxyClient user browses to a URL whose 
policy action has not already been cached on the client, the service point 
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returns the category for the URL. If the URL has not yet been categorized, the 
URL goes to DRTR. 

URLs, categories, and policy actions are temporarily cached on the 
ProxyClient computer. 

□ Dynamic Real-Time Rating (DRTR) 

A service that categorizes URLs that are not yet categorized in the BCWF 
database. 



Note: One major difference between ProxyClient Web filtering and branch 
ProxySG Web filtering is that categorization for the ProxyClient is performed 
by service points and, if necessary, DRTR. ProxyClient categorization is not 
performed by the Client Manager. 

To use ProxyClient Web filtering, you must enable the BCWF database on the 
Client Manager. However, DRTR does not need to be enabled on the Client 
Manager because DRTR lookup is always performed for any uncategorized 
ProxyClient request without the Client Manager's involvement. 



□ Policy action 

The action that is applied to a ProxyClient URL request. Possible actions are 
allow, block and warn. More information about these policy actions can be 
found in "How Blue Coat Enforces Web Filtering for Remote and Micro- 
Branch Users" . 

□ WebPulse 

The service that provides Dynamic Web Analysis; in other words, the service 
that includes the BCWF database, service points, and DRTR. 

How Blue Coat Enforces Web Filtering for Remote and Micro-Branch 
Users 

The ProxyClient filters URL requests based on the configuration file it downloads 
from the Client Manager. The configuration file determines the following: 

□ Whether or not Web filtering is enabled for the user's location. 

More information about Web filtering and location awareness can be found in 
"Enabling or Disabling Web Filtering Based on Location" on page 198. 

□ Web site categories the administrator configures on the Client Manager and 
policy actions for each. Possible policy actions are allow, warn, and block. 

URL categorization is performed either by the service point or DRTR. URLs 
and categories are stored in the BCWF database. 
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Note: One major difference between ProxyClient Web filtering and branch 
ProxySG Web filtering is that categorization for the ProxyClient is performed 
by service points and, if necessary, DRTR. ProxyClient categorization is not 
performed by the Client Manager. 

To use ProxyClient Web filtering, you must enable the BCWF database on the 
Client Manager. However, DRTR does not need to be enabled on the Client 
Manager because DRTR lookup is always performed for any uncategorized 
ProxyClient request without the Client Manager's involvement. 



For the ProxyClient to perform Web filtering, ProxySG administrators must 
enable the following features on the Client Manager: 

□ The Blue Coat Web Filter database: Configuration > Content Filtering > General. 

□ Download the current BCWF database: Configuration > Content Filtering > Blue 
Coat. 

□ Categories for use by the ProxyClient and policy actions for each: Configuration 
> ProxyClient > Web Filtering > Policy. 

More information about these options can be found in: 

□ "Configuring ProxyClient Web Filtering" on page 231 

□ Volume 7: Managing Content 

Enabling or Disabling Web Filtering Based on Location 

You can enable or disable Web filtering based on a user's location. For example, if 
the user is at headquarters or in a branch office where there is a branch ProxySG 
that performs Web filtering, you should disable ProxyClient Web filtering. You 
should enable ProxyClient Web filtering in mobile locations because mobile users 
do not connect to a branch ProxySG. 

Use location awareness to enable or disable ProxyClient features as discussed in 
"About Location Awareness" on page 182. 

The key differences between Web filtering features offered by the ProxyClient and 
the ProxySG follow: 

□ Multiple operating system support: Currently, the ProxyClient is supported 
only on Windows clients, while any computer in an ADN network can have 
Web filtering policies applied to it by a branch ProxySG. 

For details about ProxyClient operating system support, see the ProxyClient 
Release Notes. 
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□ Web filtering policies can be set per user: Using CPL or VPM, you can 
configure the branch ProxySG to apply different Web filtering policies for 
users or groups. For example, a network administrator might have a less 
restrictive Web filtering policy than an ordinary user. 

More information about performing these tasks can be found in Volume 10: 
Content Policy Language Guide or Volume 6: The Visual Policy Manager and 
Advanced Policy. 

Figure 12-5 illustrates the Web filter service decisions in a sample two-location 
configuration. 



Internet 



■< 




Figure 12-5 High-level diagram of ProxyClient Web filtering 
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In the preceding figure, two locations are defined: Mobile and Office. The 
following sections discuss how the ProxyClient processes Web filtering for each 
location: 

□ "Mobile Web Filtering Summary" 

□ "In-Office Web Filtering Summary" on page 201 

Mobile Web Filtering Summary 

This section discusses a summary of the mobile Web filtering process. For more 
detail, see "About Categorization" on page 201. 

If the user is in a mobile location without a branch ProxySG: 

1 . The user requests a URL. 

2. The ProxyClient's configuration file determines whether or not Web filtering 
is enabled for this location: 

• If ProxyClient Web filtering is disabled, the URL request goes to its 
destination. That is the end of the process. 

• If ProxyClient Web filtering is enabled, continue with step 3. 

3. The ProxyClient collects Web filtering categories from its configuration file. 

4. The ProxyClient requests a category for the URL from a service point. 

The result of the request can be one of the following: 

• The URL request is categorized by a service point, if a result was not found 
in the cache. 

• If the URL is not found in the BCWF database, the service point gets a 
categorization using DRTR. 

• If DRTR cannot determine a URL's category, the URL is categorized as 
none and the appropriate policy action is taken. 

• If no service point is available, the URL is categorized as unavailable and 
the appropriate policy action is taken. 

5. After categories are determined, the ProxyClient's configuration file 
determines the policy action (block, deny, or warn) according to the first 
match in the rulebase. 

If the policy action is warn, the user can visit the Web site for 15 minutes after 
clicking an acknowledgement link. 

6. Results of service point lookups are temporarily cached. 

See Also 

"About Categorization" on page 201 

"About Location Conditions" on page 183 

"Assigning Policy Actions to Content Categories" on page 240 

"Web Filtering Best Practices" on page 251 
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In-Office Web Filtering Summary 

This section discusses the main differences between in-office Web filtering and 
mobile Web filtering. If a user is in an office that has a branch ProxySG and if the 
user's location is identified as in the office, you should disable ProxyClient Web 
filtering in the location. 

The branch ProxySG then performs the following tasks: 

□ The branch ProxySG performs categorization and, if necessary, gets a category 
from DRTR. 

□ Specific policies defined on the branch ProxySG can be applied to users and 
groups. For example, network administrators might have less restrictive 
policy actions applied to them compared to ordinary users. 

About the BCWF Database and Categorization 

This section discusses the following topics: 
a "About the BCWF Database" 

□ "About Categorization" on page 201 

About the BCWF Database 

The Client Manager is responsible for getting the current BCWF database at least 
once every 30 days. If the database is not updated within 30 days since its last 
update, BCWF becomes inactive and all URL requests are either allowed or 
blocked, depending on the administrator's choice for the On License Expiration 
option located on the Configuration > ProxyClient > Web Filtering > Policy tab page. 



Note: The Client Manager must keep the BCWF database current for licensing 
purposes only. The ProxyClient does not use the BCWF database on the Client 
Manager; instead, it gets URL categories from a service point. 



About Categorization 

Categorization is the process of assigning a classification to a particular requested 
URL. If ProxyClient Web filtering is enabled for the user's location, the 
categorization process is as follows: 

1. The user requests a URL. 

2. The ProxyClient collects Web filtering categories from its configuration file. 
Categories are defined by the following: 

• The local database, if enabled. 

• VPM policy, if configured. 

• Results of service point lookups that are temporarily cached on the user's 
computer. 

3. The ProxyClient requests a category for the URL from a service point. 
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The result of the request can be one of the following: 

• The URL request is categorized by a service point, if a result was not found 
in the cache. 

(The cache, which is temporary, consists of results from previous lookups.) 

• If the URL is not found in the BCWF database, the service point gets a 
categorization using DRTR. 

• If DRTR cannot determine a URL's category, the URL is categorized as 
none and the appropriate policy action is applied. 

• If BCWF is not available, the URL is categorized as unavailable and the 
appropriate policy action is applied. 



Note: One Web site can have many URLs associated with it. For example, 
many Web sites have advertisements that each trigger a URL request and 
therefore a categorization request to the service point. 



4. After categories are determined, the ProxyClient's configuration file 
determines the policy action (block, deny, or warn) according to the first 
match in the rulebase. 

• If the policy action is allozv, the request goes to its destination. 

• If the policy action is block, the blocked category exception page displays. 

• If the policy action is warn, a warning message displays. 

The user must click an acceptance link, which represents an 
acknowledgment that the content request might violate corporate Web use 
policy. If the user clicks the acceptance link, the request goes to its 
destination. 

Note: If a user clicks the acceptance link, the requested Web site will be 
accessible for 15 minutes. The accessibility time period is not currently 
configurable for the Web site. 

5. Results of service point lookups are temporarily cached. 

Resolving Policy Action Conflicts 

In step 4 of the preceding procedure, suppose the same URL is listed in two or 
more categories with different policy actions. 

In the case of a conflict between policy actions, the policy action associated with 
the first rulebase match is applied. 

For example, suppose the same URL (www . example . com/news) is listed in two 
categories. One category has a policy action of allow and the other category has a 
policy action of block. 

In the table that follows, www. example . com/news is in both the Blogs/Personal 
Pages and News /Media categories. The following table shows how the conflict is 
resolved. 
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Rulebase configuration 



Selected Category Rulebase: 



Blogs/Personal Pages 


Block 


Default 


Allow 



Categories 



Action 



Move-Up 



Promote to Top 



Move-Down 



Demote to Bottom 



Selected Category Rulebase: 



Categories | Action 


Blogs/Personal Pages 




News/Media 


Allow 


Default 


Allow 





I Move-Up 




Move-Down 




1 


Promote to Top 




Demote to Bottom 





Policy action 

Because News/Media is first in the 
rulebase and its policy action is allow, 

www . example . com/ news is allowed. 



Because Blogs /Personal Pages is first in 
the rulebase and its policy action is 

block, www . example . com/ news is 

blocked. 



Note: If the user is in an office location with ProxyClient Web filtering 
disabled, a branch ProxySG performs Web filtering. For more information 
about configuring a branch ProxySG to perform Web filtering, see Volume 7: 
Managing Content. 



Blue Coat recommends you order Web filtering rules in the category rulebase as 
follows: 

1. Whitelist overrides (that is, local database and policy categories you always 
want to allow) 

2. Blacklist overrides (that is, local database and policy categories you always 
want to block) 

3. All other categories with policy action set to block 

4. All other categories with policy action set to warn 

5. All other categories with policy action set to allow 
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About Security With Guest User Scenarios 

When travelling, users might be required to initially access the Internet as a guest. 
For example, some businesses and hotels provide WiFi or hard-wired networks, 
but require users to gain access through a portal. When the user connects to the 
network and opens their Web browser, the browser redirects to a welcome page 
from which the user must interact to gain connectivity to the Internet. 

The welcome page can be as simple as a click-through service agreement or as 
complex as a service that requires a credit card payment for Internet access. After 
users complete the required agreement or transaction, they are allowed to access 
the Internet. 

When the ProxyClient detects this, it enables the user to view the welcome page 
and complete whatever authentication transaction is required to gain additional 
connectivity without applying Web filtering. After the user can connect to the 
Internet, the ProxyClient applies Web filtering policy. 

ProxyClient operates within the restricted network before completing the 
welcome page transaction, yet prevents any unauthorized user access. 

ProxyClient Security Disclaimers 

When you deploy the ProxyClient in your network, be aware of the following: 

□ Amy user with administrative privileges can disable the ProxyClient by 
stopping the service or by disabling acceleration, Web filtering, or both. 

□ Avoid allowing users with FAT and FAT32 partitions to download the 
ProxyClient for the following reasons: 

• EFS encryption is not supported; therefore, the object cache (that is, the 
byte cache and CIFS cache) will not be encrypted. 

• Because the ProxyClient uses NTFS permissions, Web filtering can be 
bypassed on FAT or FAT32 partitions and logs can be deleted. 

□ Amy user with sufficient privileges to edit files on the machine can change the 
Web filtering log files before or after they are uploaded to the FTP server. 
Because the FTP server allows anonymous access, anyone can download a log 
file, change it, and upload it again without detection (although your FTP 
server can report the source IP address used to upload log files). 

The preceding vulnerabilities can be exploited by a legitimate user or by an 
unauthorized user (such as a hacker or malware). 

□ If a user runs a VMWare image on their computer, even if the computer has 
the ProxyClient, the VMWare image can access the Internet without 
restrictions, effectively circumventing Web filtering. (The VMWare image also 
operates without acceleration.) 

To avoid this issue, install the ProxyClient software on the VMWare image. 
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Section B: Configuring a ProxySG as the Client Manager 

This section describes how to configure the ProxySG Client Manager to manage 
the ProxyClient application. 

This section includes the following topics: 

a "About ProxyClient Deployment" 

□ "Preparing the ProxySG ADN Configuration for ProxyClient Deployment" on 
page 207 

□ "Designating a ProxySG as the Client Manager" on page 210 

□ "Uploading the ProxyClient Software to the Client Manager" on page 214 

About ProxyClient Deployment 

ProxyClient deployment requires the following high-level tasks: 

□ A ProxySG administrator configures the Client Manager options, which 
define the behavior of the ProxyClient application. 

□ The user (or administrator) installs the ProxyClient application on remote and 
desktop computers (or provides instructions describing how to perform the 
installation). 

This section discusses the high-level administrator configuration tasks and client 
installation tasks. 

Before You Begin Configuring the Client Manager 

To enable the ProxyClient to perform acceleration, you must configure an ADN 
manager and optionally a backup ADN manager as discussed in "Configuring the 
ADN Managers" in Chapter 2: "Configuring an Application Delivery Network". 

Make sure you review the concepts discussed in Section A: "ADN Overview" and 
Section B: "About ADN Deployment, Compression, and Security Behavior" in 
Chapter 2: "Configuring an Application Delivery Network". 

You can also configure internet gateway settings (Configuration > ADN > Routing > 
Internet Gateway) because the ProxyClient honors internet gateway settings. For 
more information, see "Managing Server Subnets and Enabling an Internet 
Gateway" on page 38. 
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ProxySG Administrator Configuration Tasks 

The ProxySG administrator performs all of the following tasks in the order 
shown: 

1. Set up an ADN manager and optionally a backup ADN manager as discussed 
in "Before You Begin Configuring the Client Manager" on page 205. 

This enables the ProxyClient to perform acceleration. 

2. Confirm the ProxySG ADN configuration settings are compatible for 
ProxyClient deployment. 

For more information, see "Preparing the ProxySG ADN Configuration for 
ProxyClient Deployment" on page 207. 

3. Configure a ProxySG as the Client Manager, 

For more information, see "Designating a ProxySG as the Client Manager" on 
page 210. 

4. Verify the Client Manager has a valid SGOS base license. 

For more information, see "About ProxyClient Licensing" on page 181. 

5. Upload the latest Blue Coat ProxyClient software to the Client Manager. 

For more information, see "Uploading the ProxyClient Software to the Client 
Manager" on page 214. 

6. Configure the following ProxyClient options: 

• "Accelerating Network Traffic" on page 216 

• "Configuring ProxyClient Locations" on page 225 

• "Configuring ProxyClient Web Filtering" on page 231 

7. Provide the ProxyClient software to users in one of the ways discussed in this 
chapter. 

For more information, see "Distributing the ProxyClient Software" on page 
266. 
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Client Installation Tasks 

The ProxyClient deployment process involves the following: 

1. Am administrator provides the ProxyClient software URL displayed on the 
Client Manager to users or pre-installs the application using SMS or another 
software distribution system before issuing the system to a user. 



Note: To run ProxyClientSetup.exe and ProxyClientSetup.msi, the user 
must be in the Administrators group on the computer. 



When the person performing the installation enters the URL, a setup 
application (ProxyClientSetup.exe) runs that in turn downloads and starts a 
Microsoft Installer (ProxyClientSetup.msi). 



Note: Installation methods are discussed in Section D: "Distributing the 
ProxyClient Software" on page 266. 



2. After installing the ProxyClient software, the user must reboot the machine. 

3. Periodically, the ProxyClient polls the Client Manager for changes to the 
ProxyClient software and configuration. 

Preparing the ProxySG ADN Configuration for ProxyClient Deployment 

To use the ProxyClient in your ADN network, you must configure options for 
Manager Listening Mode and Tunnel Listening Mode on the ADN manager and 
backup manager (if any) as discussed in this section. 

The ProxyClient does not publish routes; it obtains routes from the ADN 
manager. Also, the ProxyClient uses plain communications only. The options you 
select for manager listening mode and tunnel listening mode must be compatible 
with the ProxyClient. 

This section discusses the following topics: 

□ "About Manager Listening Mode" on page 208 

□ "About Tunnel Listening Mode" on page 209 

□ "About Secure Outbound Mode" on page 209 

Note: To select options for either manager listening mode or tunnel listening 
mode, you must have previously set up an SSL device profile on the ProxySG. 
For more information about SSL device profiles, see "About SSL Device 
Profiles" on page 116. 
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About Manager Listening Mode 

Manager listening mode determines the way routes are published in the ADN 
network: using the plain manager port (non-secure communication) or the secure 
manager port (secure communication), or both. 

Select manager listening mode options on the ADN manager and backup 
manager only. Manager listening mode options are not available on other 
ProxySG appliances. 

For more information about setting the plain manager port and the secure 
manager port, see "About the ADN Manager" on page 30. 

As discussed in "Securing Connections" on page 49, the following options are 
available: 

□ Secure Only 

Only ProxySG appliances using secure connections can publish routes. 
However, because selecting this option means that only the secure listener is 
active, you cannot select this option if you have ProxyClients in your ADN 
network because ProxyClients use only plain connections. 

□ Plain Read-Only 

Select this option if all ProxySG appliances in the ADN network use SGOS 
version 5.1.4 or later — where all appliances support secure routing, and you 
have enabled secure routing on those ProxySG appliances. 

This option means that ProxySG appliances that use secure connections can 
publish routes. Devices that use plain communications can obtain routes but 
cannot publish routes. 



Note: Select this option only if all appliances in the ADN network run SGOS 
version 5.1.4 or later. 



□ Plain Only 

Select this option in cases where you do not secure any ADN connections 
between ProxySG appliances. 

This option means that only ProxySG appliances that use plain connections 
can publish routes. 

□ Both 

Select this option if you use the ProxyClient in your ADN network and some 
appliances in the network are not capable of using secure connections (for 
example, some appliances run SGOS version 5.1.3 or earlier). 

This option means that ProxySG appliances that use either secure or plain 
connections can publish routes. If secure is enabled and available, it is used by 
default. 
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About Tunnel Listening Mode 

Tunnel listening mode determines the type of incoming tunnel communications 
this ProxySG appliance accepts: using the plain tunnel port (non-secure 
communications) or the secure tunnel port (secure communications). 

Select options for tunnel listening mode on every concentrator to which you 
expect ProxyClients to connect. For example, select a tunnel listening mode 
option for the concentrator discussed in "About Tunnel Listening Mode" on page 
209. 

For more information about the plain tunnel port and the secure tunnel port, see 
"Securing Connections" on page 49. 

The following options are available: 

□ Secure Only 

This option means the ProxySG appliance accepts only secure tunneling 
connections. Because the ProxyClient uses only plain connections, you cannot 
select this option if you have ProxyClients in your ADN network. 

□ Plain 

Select this option to enable the ProxyClient to connect to the appliance in cases 
where you do not secure any ADN connections between ProxySG appliances. 

This option means this appliance accepts only plain tunneling connections. 

□ Both 

Recommended for ProxyClient deployments in ADN networks in which secure ADN 
is used. Select this option if you use the ProxyClient in your ADN network and 
some appliances in the network use secure ADN. This option also enables you 
to support appliances that are not capable of accepting incoming secure 
tunneling connections (for example, some appliances run SGOS version 5.1.3 
or earlier). 

This option means this appliance accepts both plain and secure tunneling 
connections. 

About Secure Outbound Mode 

The Secure Outbound Mode options have no impact on the ProxyClient because 
these options determine how ProxySG appliances communicate with each other. 
For a tunneling connection to be established between two ProxySG appliances, 
the initiating appliance's secure outbound mode must be compatible with the 
tunnel listening mode of the receiving appliance. 
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Designating a ProxySG as the Client Manager 

This section discusses how to configure an appliance in the ADN network as the 
Client Manager. 

You must configure one ProxySG in your ADN network as the Client Manager. 
The Client Manager is responsible for providing the ProxyClient software, 
software updates, and client configuration to ProxyClient applications installed 
on user computers. 



Note: The Client Manager can be a different appliance than the ADN manager 
or the backup ADN manager. That is, you can configure the ADN manager or 
the backup ADN manager as the Client Manager, but it is not required. 



Before You Configure the Client Manager 

Before you configure the Client Manager, make sure you performed all of the 
following tasks: 

□ "Before You Begin Configuring the Client Manager" on page 205 

□ "Preparing the ProxySG ADN Configuration for ProxyClient Deployment" on 
page 207 

□ "About ProxyClient Licensing" on page 181. 



Designating the Client Manager 

This section discusses how to designate a ProxySG concentrator as the Client 
Manager. 



To designate a ProxySG as the Client Manager: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Click ProxyClient > General > Client Manager. 



Client Manager Client Software | Locations 

0 Enable Client Manager 

|- Client Manager 

Host: ® Use host from initial client request 



0 Use host: 



8084 



Port: 

Keyring: default 

Update interval: 



120 



minutes 



3. On the Client Manager tab page, select the Enable Client Manager check box. 
This designates this ProxySG as a Client Manager. 



210 




Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient) 



Section B: Configuring a ProxySG as the Client Manager 

4. In the Client Manager section, enter or edit the following information: 
Table 12-1 Client Manager options 



Option 


Description 


Host section 


Specify the host from which users get the ProxyClient software, 
configuration, and updates. Blue Coat recommends you specify a fully 
qualified host name, and not an unqualified (short) host name or IP 
address. If you use a fully qualified host name and the Client Manager's IP 
address changes later, you need only to update DNS for the Client 
Manager's new address and clients can continue to download the software 
and updates from the Client Manager. 

You have the following options: 

• Use host from initial client request: ( Recommended .) Select this option to 
enable clients to download the ProxyClient software, configuration, and 
updates from the host from which the clients originally obtained the 
software and configuration. In other words, in a typical ProxyClient 
deployment, the administrator e-mails users a URL from which they 
obtain the ProxyClient software and configuration initially. The host 
name or IP address in this URL is used to download the software to the 
client and is written to the client's configuration file for use in future 
software and configuration updates. 

This option is compatible with all methods of deploying the ProxyClient, 
including Windows Group Policy Object (GPO) and Microsoft Systems 
Management Server (SMS). For more information about these 
deployment options, see Section D: "Distributing the ProxyClient 
Software" on page 266. 

• Use host: Select this option to download the ProxyClient software and 
configuration from the host name you specify. Enter a fully qualified 
host name or IP address only; do not preface it with http : / / or 
https : // because downloads will fail. 

Use this option to migrate users from one Client Manager to another 
Client Manager. (Also see "Changing the Client Manager" on page 313.) 


Port field 


Enter the port on which the Client Manager listens for requests from 
clients. The default is 8084. 


Keyring list 


Click the name of the keyring to use when clients connect to the Client 
Manager. 


Update Interval field 


Specify the length of time (in minutes) between update checks. For 
example, if the value is 120, each ProxyClient application connects to the 
Client Manager every 120 minutes for configuration and software updates 
(beginning at startup). 

Valid values are 10-432000 (that is, 300 days). The default is 120 minutes. 



After you apply the changes, the Client Components section displays a summary 
of the information you selected. 
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|- Client Components 

Client setup: 

Client install MSI: 

Client configuration: 

Client configuration last 
modified: 



https : //host-f rom-dient-request : 8084/proxydient/ProxyClientSetup . exe 
https: //host-f rom-dient-request : 8084/proxydient/ProxyClientSetup. msi 
https: //host-f rom-dient-request : 8084/proxydient/ProxyClientConfig . xml 

January 29 , 2008 10:54:51 AM PST 



Table 12-2 discusses the meaning of this information. 



Table 12-2 Client Components section 



Item 


Description 


Client setup 


Displays the URL from which users download the 
ProxyClient setup application. The setup application 
(ProxyClientSetup . exe) downloads the Microsoft installer 
(ProxyClientSetup.msi) to the client. 

This information is intended for interactive client 
installations from the Client Manager; for more information, 
see "Preparing Interactive Installations" on page 268. 

Provide this URL to users so they can install the ProxyClient 
software on their computers. To install the software this way, 
the user must have administrator privileges on the client 
machine. 

Note: If you selected Use host from client request for Host, 

the URL displays as follows: 

https : //host-from-client-request: 8084/ 
proxyclient/ProxyClientSetup . exe 

To download the ProxyClient using this URL, substitute the 
Client Manager's host name or IP address for host-from- 
client-request. 


Client install MSI 


Displays the URL from which ProxyClientSetup . exe 
downloads ProxyClientSetup.msi. 

This information is intended for non-interactive installations 
using Group Policy Objects (GPO) or the Microsoft Systems 
Management Server (SMS), as discussed in "Using Group 
Policy Object Distribution" on page 285. 

Note: Blue Coat recommends users not run the . msi on their 
computers because the installation fails unless the user 
enters parameters on the command line (for example, 

BCSI updateurl). 
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Table 12-2 Client Components section 



Item 


Description 


Client configuration 


Displays the URL from which the ProxyClient installer 
downloads the client configuration file 

(ProxyClientConf ig . xml). 

This information is provided for your reference only. This 
URL must be used as the value of the bcs I updateurl 
parameter for silent, GPO, or SMS installations. For more 
information, see one of the following sections: 

• "Preparing Silent Installations and Uninstallations" on 
page 273 

• "Using Group Policy Object Distribution" on page 285 


Client configuration 
last modified 


Displays the most recent date and time 

ProxyClientConf ig . xml was updated on the Client 
Manager. 



See Also 

Section D: "Distributing the ProxyClient Software" on page 266 
"About the Roles of ProxySG Appliances With the ProxyClient" on page 178 
"Setting the Client Manager (CLI)" on page 261 
"Configuring General ProxyClient Settings (CLI)" on page 261 
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Uploading the ProxyClient Software to the Client Manager 

This section describes how to upload the latest ProxyClient software to the Client 
Manager to make it available to install or to update on client machines. 



Important: After you update the ProxyClient software on the Client Manager, 

whenever users connect using the ProxyClient, they must update their 
ProxyClient software unless software updates are disabled. You have the option 
of disabling software updates from the Client Manager if you plan to distribute 
updates some other way (for example, by GPO or SMS). For more information, 
see "Parameters for Silent Installations" on page 274. 

Before uploading the ProxyClient software, verify the Client Manager is running 
compatible SGOS software. For example, ProxyClient 3.1.x requires SGOS 5.3.x. 



To upload ProxyClient. car to the Client Manager: 

1. Get ProxyClient . car as follows: 

a. Log in to WebPower by entering your credentials at the following 
URL: 

http : / /webpower . bluecoat . com 

If you do not have a WebPower login, register at http:/ / 
webpower.bluecoat.com/ register. 

b. Click Download Software. 

c. On the Downloads page, click the Blue Coat ProxyClient link. 

d. Click the link to request the ProxyClient software. 

e. When prompted, enter your WebPower credentials. 

f. A link to the software will be e-mailed to the user who registered with 
WebPower. 

g. Follow the prompts in the e-mail to download ProxyClient . car. 

2. Locate ProxyClient . car in any of the following: 

• On the local file system of the computer you run the Client Manager's 
Management Console. 

That is, to upload the ProxyClient software from your local file system or 
from a network share drive (as opposed to uploading it from a remote 
URL), you must copy ProxyClient . car to an accessible location. 

• On a Web server the Client Manager can access. 

3. Log in to the Client Manager's Management Console as an administrator. 

4. Click ProxyClient > Client Manager > Client Software. 

The Current ProxyClient Software section displays information about the 
ProxyClient software this Client Manager is currently using. 

5. From the Install ProxyClient software from list, click one of the following: 
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• Remote URL: Upload ProxyClient . car from a location specified by a URL in 
the following format: 

http : II host :por t /pa th/ProxyCl ient_ version . car 

For example, 

http : / /myapache . example . com/ sof tware/ProxyClient_3 . 1 . 1 . 1 . car 

• Local file: Upload the ProxyClient software from a location accessible by 
the machine on which you are running the Management Console. 

6. Click Install. 

7. Follow the displayed prompts to complete the upload. 

8. Clients get the updated software at the next update interval. 
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Section C: Configuring the ProxyClient 

The Client Manager enables you to configure the following options for the 
ProxyClient: 

a "Accelerating Network Traffic" 

□ "Configuring ProxyClient Locations” on page 225 

□ "Configuring ProxyClient Web Filtering" on page 231 

For more information about these options, see Section A: "ProxyClient Concepts" 
on page 174. 

Accelerating Network Traffic 

This following sections discuss how to configure the WAN acceleration options 
on the Client Manager: 

□ "Before You Begin Configuring ProxyClient Policy" 

□ "Specifying the ProxyClient ADN Manager" on page 217 

□ "Tuning the ADN Configuration" on page 218 

□ "Enabling File Sharing Acceleration" on page 221 

□ "Enabling ProxyClient Acceleration" on page 223 

Before You Begin Configuring ProxyClient Policy 

Before performing the tasks discussed in this section, you must configure your 
ADN manager to route subnets; otherwise, no network traffic will be accelerated. 

On all concentrators that front servers to which you want to accelerate 
ProxyClient traffic, click Configuration > ADN > Routing > Server Subnets. For 

additional assistance, click Help or see "Managing Server Subnets and Enabling an 
Internet Gateway" on page 38. 

Because the ProxyClient also accelerates Internet traffic, you can set Internet 
gateway options: Configuration > ADN > Routing > Internet Gateway. For more 
information, see "Managing Server Subnets and Enabling an Internet Gateway" 
on page 38. 
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Specifying the ProxyClient ADN Manager 

This section discusses how to specify the ADN manager that will publish routes 
to the ProxyClient. 



To specify the ADN manager for the ProxyClient: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Click Configuration > ProxyClient > Acceleration > ADN Manager. 



General ADN Manager ADN Rules | CIFS 

r ADN Manager 

Primary manager IP address: 

Backup manager IP address: 

ADN manager port: 

3. On the ADN Manager tab page, enter or edit the following information: 



192 . 9 . 9.9 



192 . 9 . 9.0 



3034 



Field 


Description 


Primary manager IP address 


Enter the IP address of the ADN manager for the 
ADN network to which the ProxyClient connects. 
For more information about the role of the ADN 
manager, see "Terminology" on page 175 and "About 
the Roles of ProxySG Appliances With the 
ProxyClient" on page 178. 


Backup manager IP address 


Enter the IP address of the backup ADN manager, if 
any. 


ADN manager port 


Enter the ADN manager's plain listen port (by 
default, 3034). 



Important: Do not enter a secure port number, because the ProxyClient 

version 3.1.x does not support secure tunnels. 



4. Click Apply. 
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5. If you have not already done so, perform the following tasks to enable 
ProxyClient acceleration: 

a. Click Configuration > ProxyClient > Acceleration > General. 

b. In the right pane, click the Enable Acceleration check box. 

c. Click Apply. 

You must also enable acceleration for locations as discussed in "Configuring 
ProxyClient Locations" on page 225. 

Tuning the ADN Configuration 

The ProxySG enables you to customize include and exclude subnets and port lists, 
which are advanced settings that limit the traffic that is accelerated by the ADN 
network. Because the ADN manager sets options for both its peers in the ADN 
network and for ProxyClients, you can use the include or exclude ports list to 
fine-tune the way ProxySG appliances interact with the ProxyClient. 

For example, if you know that ProxyClient traffic over particular ports is not 
compressible, you can add those ports in the exclude ports list. Blue Coat strongly 
recommends you test the include/ exclude ports settings in a controlled 
environment before using them in production because improper settings can have 
an adverse impact on performance. 

Specifically, you must understand the following: 

□ Excluded subnets — You can exclude intranet connections from being 

forwarded to a ProxySG configured as an Internet gateway. This is important 
if your network is designed such that a connection to an intranet server fails if 
it is sent through an Internet gateway. 

Provided an Internet gateway is configured, forwarding occurs as follows: 

a. If the destination IP address is a local address, do not attempt to use an 
ADN tunnel; instead, connect directly. This is the end of the process. 

b. If the destination IP address is in the ProxyClient's excluded subnets 
list, do not attempt to use an ADN tunnel; instead, connect directly. 

This is the end of the process. 

Otherwise, if the IP address is not in the ProxyClient's exclude list, 
continue with the next step. 

c. If the destination IP address matches an entry in the ADN routing 
table, forward the connection over an ADN tunnel; otherwise, 
continue with the next step. 

d. If a ProxySG is configured as an Internet gateway, look up the 
destination IP address in the Internet gateway's exception list. 

If the address does not match, forward the connection over an ADN tunnel 
to the Internet gateway; otherwise, connect directly to the destination IP 
address. 
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□ Include and exclude ports — Includes or excludes TCP ports in ADN tunnels. 
Assuming ProxyClients can connect to a ProxySG that can optimize traffic to 
the destination address, this setting determines which ports are accelerated 
(or are not accelerated) for clients. You can use either the excluded ports list or 
included ports list, but not both. 

See one of the following sections for more information: 
a "Excluding Subnets from Being Accelerated" 

□ "Excluding and Including Ports" on page 220 

Excluding Subnets from Being Accelerated 

This section discusses how to prevent subnets from being accelerated when 
clients connect using the ProxyClient. 

To exclude subnets: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Click Configuration > ProxyClient > Acceleration > ADN Rules. 

3. On the ADN Rules tab page, in the Excluded Subnets section, click Add. 

The Add IP/Subnet dialog displays. 



General | ADN Manager ADN Rules CIFS 

r Excluded Subnets 




Excluded Subnets 
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4. Enter or edit the following information: 



Option 


Description 


IP / Subnet Prefix field 


Enter either an IP address or an IP 
address and subnet in Classless Inter- 
Domain Routing (CIDR) notation (for 
example, 192.168.0.0/16). 


Subnet Mask field 


Use this field if you entered only an IP 
address in the preceding field (that is, if 
you used CIDR notation in the 
preceding field, you do not need to 
enter a value in this field). 



5. In the Add IP/ Subnet dialog, click OK. 

6. Repeat these tasks to exclude more subnets, if required. 



Excluding and Including Ports 

This section discusses how to include and exclude from traffic on certain TCP 
ports; in other words, traffic on these ports either will be accelerated (if included) 
or will not be accelerated (if excluded). Note that if you include ports, all other 
traffic is not accelerated. 

To exclude or include ports: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Click Configuration > ProxyClient > Acceleration > ADN Rules. 

The ports section displays. 




3. In the Ports section, click one of the following options: 

• Exclude: Client traffic from specified ports is not routed through the ADN 
tunnel. All other traffic is accelerated. 

Valid values: Comma-separated list of ports and port ranges (no spaces, 
separated by a dash character). For example: 

22 , 88 , 443 , 993 , 995 , 1352 , 1494 , 1677 , 3389 , 5900-5902 
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• Include: Client traffic from specified ports is routed through the ADN 
tunnel and therefore is accelerated. All other traffic bypasses the tunnel 
and is not accelerated. 

Valid values: Comma-separated list of ports and port ranges (no spaces, 
separated by a dash character). For example: 

80 , 139 , 445 , 8080-8088 

Include ports 139 and 4 45 for file sharing (CIFS services) acceleration. 



Note: The include and exclude ports lists are advanced settings that limit the 
traffic that is accelerated by the ADN network. 



4. Click Apply. 

Enabling File Sharing Acceleration 

This section discusses how to enable the ProxyClient to enable Common Internet 
File System (CIFS) protocol acceleration, which is the protocol used to send files 
and directories across the WAN. Using CIFS acceleration improves performance 
when users request the same files from a file server at headquarters, for example. 



Note: The ProxyClient does not perform CIFS acceleration in the following 
conditions: 

• to a server that has SMB message signing enabled. For more 
information, see Microsoft KB article 887429. 

• to a server that uses SMB 2.0 

• other conditions discussed in the ProxyClient Release Notes 

For file sharing conceptual information, see "ADN Features" on page 192. 

For more detailed information about CIFS optimization on the ProxySG, see 
the Acceleration File Sharing chapter in Volume 2: Proxies and Proxy Services of 
the ProxySG Configuration and Management Documentation Suite 



To enable file sharing acceleration using the ProxyClient: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Verify the CIFS ports are listed in the Included Port list as discussed in 
"Enabling File Sharing Acceleration" on page 221. 

3. Click Configuration > ProxyClient > Acceleration > CIFS. 
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The CIFS tab page displays. 



General ADN Manager | ADN Rules CIFS 



@ Inffle^KjBcoetej^jort 



Write Back: 



0 Full 0 None 



Directory cache time: 



30 



seconds 



4. On the CIFS tab page, enter or edit the following information: 



Option 


Description 


Enable CIFS 
acceleration check box 


You must select this check box to enable clients to accelerate 
CIFS traffic. 


Write Back options 


Write back options determine whether or not user 
connections continue sending data to the ProxySG 
appliance while the appliance is writing data on the back 
end. Select one of the following: 

• Select Full to enable write-back, which causes the 
ProxyClient to sending data to the appliance without 
waiting for acknowledgement that the data was written 
successfully. 

This setting improves responsiveness but can lead to data 
loss if the ProxyClient crashes or the link drops before 
delivering all the data to the ProxySG appliance. 

• Select None to disable write-back. Disabling write-back 
can introduce substantial latency while clients send data 
to the appliance and wait for acknowledgement before 
sending more data. 

One reason to set this option to None is the risk of data 
loss if the link from the branch to the core server fails. 
There is no way to recover queued data if such a link 
failure occurs. 


Directory cache time 

field 


Enter the number of seconds for directory listings to remain 
in the client's cache. 



5. Click Apply. 
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See Also 

Volume 2: Proxies and Proxy Services 

"ADN Features" on page 192 

"Clearing the Cache" on page 323 

"Changing the Location of the Cache" on page 324 



Enabling ProxyClient Acceleration 

After you have configured your network parameters (ADN manager information, 
excluded subnets, included or excluded ports, and CIFS protocol options), you are 
ready to enable acceleration for the ProxyClient. 



To enable ProxyClient acceleration: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. If you have not already done so, perform the following prerequisite tasks: 

a. Enable the Client Manager as discussed in "Designating a ProxySG as 
the Client Manager" on page 210. 

b. Specify the ADN manager as discussed in "Specifying the ProxyClient 
ADN Manager" on page 217. 

3. Click Configuration > ProxyClient > Acceleration > General. 



General ADN Manager , ADN Rules | CIFS 



General Settings 



0 Enable Acceleration 
Acceleration License: Valid 

Maximum percentage of disk space to use for caching: ig 



4. On the General tab, enter or edit the following information: 



Option 


Description 


Enable Acceleration 


You must select this check box to enable ProxyClient 
to accelerate network traffic using all of the following 
methods: 

• gzip 

• CIFS protocol acceleration 

• byte caching 

If you clear the check box, the ProxyClient performs 
no acceleration. 
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Option 


Description 


Acceleration License 


Displays the status of your acceleration license as 
either Valid or Invalid. 

The ProxyClient — Acceleration license component is 
part of the base SGOS license. If the status is invalid, 
there is a problem with your Blue Coat license. 

Verify a valid base SGOS license is installed 

(Maintenance > Licensing > View). Contact Blue Coat 
Support for license troubleshooting issues. 


Maximum percentage of disk 
space to use for caching field 


Enter the maximum percentage of total client disk 
space (as opposed to available disk space) to use for 
caching objects, such as CIFS objects. Valid values are 
1-90; the default is 10. 

The higher you set the value, the more information is 
cached on user systems, but at the expense of disk 
space that might be required to run other applications. 

See also: 

• "Clearing the Cache" on page 323 

• "Changing the Location of the Cache" on page 324 



5. Click Apply. 



More About ProxyClient Caching 

The following is a summary of how CIFS protocol acceleration and byte caching 
work on the client computer: 

1 . The ProxyClient starts. 

2. The user requests a cacheable object, such as a file. 

3. The ProxyClient allocates sufficient disk space on the client computer to cache 
the object — up to the limit set by the administrator. That is, if the client 
computer's system has 100GB of total space and the administrator configures 
the cache to use a maximum of 10%, the ProxyClient allocates up to 10GB for 
the cache. 

Cache space is divided equally between the CIFS cache and the byte cache. 

However, if the maximum cache size leaves less than 1GB of available disk 
space, the cache size is further limited. Continuing this example, if the client 
has only 9GB of available space, the maximum cache size is 8GB instead of 
10GB. 

4. If any single object (such as a file) exceeds the maximum CIFS cache size, that 
object is not cached in the CIFS cache; however, tokens associated with the 
object are cached in the byte cache. 
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For example, if the maximum size of the CIFS cache is 5GB, and the client 
requests a file that is 6GB in size, that file is not cached in the CIFS cache. 

5. If the cache is full, objects are expired from the cache based on a number of 
criteria, such as unopened files and oldest objects first. 



Note: For details about where the cache files are stored by default and for 
information about how to change the location of cache files, see "Changing the 
Location of the Cache" on page 324. 



Configuring ProxyClient Locations 

The ProxyClient application automatically detects its location by matching a 
combination of IP address, virtual NIC IP address, and DNS server address as 
specified by the ProxySG administrator. 

The purpose of configuring locations is to enable ProxyClient features based on 
where the user connects. For example, a user who works from home on a laptop 
needs the ProxyClient to perform both acceleration and Web filtering because the 
user does not connect to a network with a local ProxySG that performs those 
functions. However, if the user brings the same laptop to work, both ProxyClient 
acceleration and Web filtering should be disabled because a local ProxySG 
concentrator or branch appliance performs those functions. 

This section discusses the following topics: 
a "Configuring Specific Locations" 

□ "Configuring Default Actions" on page 230 

For an overview and examples, see "About Location Awareness" on page 182. 

Location Awareness Task Summary 

The following table summarizes the tasks required to set up location awareness: 



Task 


Description 


1. "About Location Conditions" on 
page 183 


Understand your network; specifically, how 
clients use VPN to access your network, IP 
source address ranges, and DNS server IP 
addresses. 


2. "Location Example” on page 184 


Plan your locations. 


3. "Configuring Specific Locations" 
on page 226 


Configure locations for office, branch office, 
home office, and mobile users. 


4. "Configuring Default Actions" on 
page 230 


Default actions are used for users that do not 
match any configured locations. 


5. "Ordering Locations in the 
Rulebase" on page 229 


To make sure users match the correct location, 
put the most restrictive (that is, more specific) 
locations in the rulebase before less restrictive 
locations. 
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Configuring Specific Locations 

This section discusses how to use location conditions to define specific locations, 
such as office headquarters, branch offices with ProxySG concentrators, and 
mobile users. 

For more information and examples, see the following sections: 

□ "About Location Conditions" on page 183 

□ "About Condition Rulebase Ordering" on page 191 

To specify locations: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Select Configuration > ProxyClient > General > Locations. 

3. On the Locations tab page, click New. 

The New Locations dialog displays. 

4. In the Name field, enter a name that identifies this location. For example. 

Headquarters. 

Note: The location name cannot be changed later. 



5. In the Conditions section, select one or more conditions that define this 
location. 

The Conditions section enables you to specify one or more conditions that 
define the location, and therefore the ProxyClient features to apply to users in 
the location. For more information and examples of setting up locations, see 
the following sections: 

• "About Location Conditions" on page 183 

• "About Condition Rulebase Ordering" on page 191 
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To add a location condition, perform the following tasks: 



Condition 


Tasks 


Source IP ranges 


1. Select the Match source IP ranges check box. 

2. Click New. 

Note: You cannot directly edit an existing condition. First delete 
the existing condition and then add a new one. 

3. In the Add IP Source Range dialog, enter a starting and ending 
IP address in the provided fields. 

You must enter a pair of IP addresses; you cannot enter CIDR 
notation. 

4. Click OK. 

5. Repeat these tasks to enter other source IP address ranges if 
required. 

Note: This condition is matched if the user has an IP address in 
any of the ranges you define. 


DNS servers 


1. Select the Match DNS servers checkbox. 

2. Click New. 

Note: You cannot directly edit an existing condition. First delete 
the existing condition and then add a new one. 

3. In the Add DNS Servers IPs dialog, enter the server's IP 
address. 

4. Click OK. 

5. Repeat these tasks to enter other DNS server IP addresses if 
required. 

Note: This condition is matched only if all DNS servers are 
matched. For example, if the location defines DNS IP addresses 

10.1.1.1 and 10.1.1.2, and the user 's computer has only 

10.1.1.2 defined, there is no match. However, if the location 
condition defines DNS IP addresses 10 . l . l . l and 10.1.1.2, 
and the user's computer has 10.1.1.1,10.1.1.2, and 

10.1.1.3 defined, there is a match. 
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Condition 


Tasks 


Virtual NIC IP 
ranges 


1. Select the Match Virtual NICs IP check box. 

2. Click New. 

Note: You cannot directly edit an existing condition. First delete 
the existing condition and then add a new one. 

3. In the Add Virtual NIC IP Range dialog, enter a starting and 
ending IP address in the provided fields. The range you enter 
should correspond to a range of IP addresses provisioned by 
your VPN gateway. 

You must enter a pair of IP addresses; you cannot enter CIDR 
notation. 

4. Click OK. 

5. Repeat these tasks to enter other Virtual NIC IP address ranges 
if required. 

Note: This condition is matched if the user has an VNIC IP 
address in any of the ranges you define. 



6. Select the check box corresponding to which features are enabled for this 
location: 



• Enable Acceleration: Select this option to accelerate network traffic using all 
of the following: 

• g zi P 

• CIFS protocol acceleration 

• byte caching 

• Enable Web Filter: Select this option to perform Web filtering in this location. 



Important: All selected conditions must match to enable the selected 
location features. For example, if Source IP Address and DNS Servers 
conditions are selected, and if the user matches the source IP address but not 
the DNS server IP address, the user does not match this location and the 
features enabled by the location will not be applied to the user. 

Users who do not match any location conditions have default actions 
applied to them as discussed in "Configuring Default Actions" on page 230. 



7. Click OK. 



The location name and 
associated policy actions 
display on the Locations tab 
page. 



Client Manager | Client Software | Locations 




228 




Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient) 



Section C: Configuring the ProxyClient 

See Also 

"Overview of Location Awareness" on page 182 
"About Location Conditions" on page 183 
"About Condition Rulebase Ordering" on page 191 

Ordering Locations in the Rulebase 

The order in which locations display on the Configuration > ProxyClient > General > 
Locations tab page determine the order in which the rules are evaluated when 
users connect to the Client Manager. To avoid mismatches, order the rules from 
most to least restrictive. 

For example, suppose headquarters uses IP addresses in the range from 10.0.0.0 to 
10.255.255.255 but the VPN gateway located at headquarters has a pool of IP 
addresses in a subset of that range; for example, 10.3.1.1 to 10.3.1.255. Because the 
VPN gateway is used by home office or mobile users, the administrator wants to 
use different policy actions for headquarters and home office users. 

Users at the headquarters location should have ProxyClient acceleration and Web 
filtering disabled but users in a home office or mobile location should have both 
ProxyClient features enabled. 

To accomplish that, the administrator creates the two locations as follows. 



Location 


Conditions 


Headquarters 


• Source IP address range: 10.0.0.0 to 10.255.255.255 

• DNS server IP address: For example, 10.0.0.11 and 
10.0.0.12 


Home office or mobile 


• DNS server IP address: Same as headquarters 

• VNIC IP address range: 10.3.1.1 to 10.3.1.255 



To make sure the home office or mobile location is detected first, the administrator 
must order it in the rulebase before the headquarters location. An example 
follows. 



Client Manager 1 Client Software Locations 
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Configuring Default Actions 

The purpose of default actions is to enable ProxyClient features for users that do 
not match any location conditions you defined earlier. 

For example, mobile users that do not connect to the network using VPN have 
unknown source IP ranges and DNS servers. If a mobile user connects to the 
network using VPN, the user has a VNIC IP address you can use to establish the 
user's location. 

To configure default actions: 

1. Log in to the Management Console as an administrator. 

2. Click Configuration > ProxyClient > General > Locations. 

3. At the bottom of the Locations tab page, in the Default Actions section, select 
the check box corresponding to features to enable for clients who do not 
match any defined location conditions. 

The following figure shows an example of enabling both acceleration and Web 
filtering by default: 















New Edit Delete Promote Demote 






1^1 Enable Acceleration @ Enable Web Filter 





See Also 

"Overview of Location Awareness" on page 182 
"About Location Conditions" on page 183 
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Configuring ProxyClient Web Filtering 

This section discusses how to configure the Client Manager to provide the Blue 
Coat Web Filtering service for ProxyClient users. Web filtering enables you to 
allow, block, or warn users about accessing content in categories you specify 
using any of the following: 

□ The Blue Coat Web Filtering database categories 

□ Local database categories 

□ Policy categories (also referred to as custom categories) 

□ System and Default categories, which are discussed in more detail later in this 
section 

For conceptual information about Web filtering, see "About ProxyClient Web 
Filtering" on page 196. 

Web Filtering Task Summary 

To use ProxyClient Web filtering, you must perform the following tasks in the 
order shown: 



Task 


Description 


1. Prerequisites 


• "About ProxyClient Licensing” on page 181 

The use of BCWF depends on proper licensing on 
the Client Manager. 

• "Designating a ProxySG as the Client Manager" 
on page 210 

You must designate a Client Manager before you 
can enable Web filtering for the ProxyClient. 


2. "Enabling the Blue Coat Web Filter 
Database" on page 233 


The BCWF database must be enabled on the Client 
Manager before ProxyClient Web filtering can be 
enabled. 

Note: Although it is possible to enable other 
databases (for example, Internet Watch Foundation), 
only the following categories can be used by the 
ProxyClient: 

• Blue Coat Web Filter 

• Policy, such as VPM policy 

• The local database 

• System and Default categories 

Categories from other databases are not used by 
ProxyClient Web filtering. 


3. "Setting up the BCWF Database 
Download" on page 234 


Set up updates for the BCWF database; the database 
must be updated on the Client Manager at least 
once every 30 days. 
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Task 


Description 


4. Optional. "Enabling the Use of the Local 
Database (Optional)" on page 236 


The local database is one way you can optionally 
create categories to whitelist or blacklist specific lists 
of URLs for your employees. 

You can also add policy categories (also referred to 
as custom categories) to set up whitelists and 
blacklists. For more information, see "Managing 
Policy Categories" on page 242. 


5. "Enabling ProxyClient Web Filtering" on 
page 238 


After you have the current BCWF database, you can 
enable the ProxyClient to perform Web filtering. 


6. "Assigning Policy Actions to Content 
Categories" on page 240 


Define categories of content you will allow users to 
access, block users from accessing, or warn users 
about accessing. 


7. "Web Filtering Best Practices" on page 251 


Information about how to best use Web filtering in 
your corporation. 


8. "Displaying and Customizing Web 
Filtering Exception Pages" on page 253 


Exception pages are displayed to users when they 
attempt to access content that the administrator 
chose to either block or to warn about. Blue Coat 
recommends you customize the default exception 
pages to provide users with more specific 
information. 


9. "Enabling Web Filtering Logging" on 
page 256 


How to upload user Web filtering logs to an 
anonymous FTP server. 
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Enabling Blue Coat Web Filtering 

Before Web filtering can be enabled for the ProxyClient, Blue Coat Web Filtering 
must be enabled on the Client Manager. 

You must obtain a BCWF license, which entitles you to a BCWF user name and 
password. For more information, contact your Blue Coat representative. Because 
the BCWF database must be updated at least once every 30 days, make sure the 
Client Manager is capable of accessing the Internet. 



Note: The Client Manager must keep the BCWF database current for licensing 
purposes only. The ProxyClient does not use the BCWF database on the Client 
Manager; instead, it gets URL categories from a service point. 



Enabling the Blue Coat Web Filter Database 

This section discusses how to enable the use of the Blue Coat Web Filter database, 
which is required for ProxyClient Web filtering. 



Note: Blue Coat Web Filtering must be enabled on the Client Manager; however, 
DRTR does not need to be enabled. ProxyClient categorization does not occur on 
the Client Manager; instead, the ProxyClient gets categories from a service point. 
The service point gets a category from DRTR if the URL is not already categorized 
in the BCWF database. 



To enable the Blue Coat Web Filter database: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Click Configuration > Content Filtering > General. 



General 



Providers 

Provider Enable 

Local Database: 

Internet Watch Foundation: g 

Blue Coat Web Filter: g 

3rd-party database: fg one 



Lookup mode 

©Always O Uncategorized 
©Always O Uncategorized 
©Always O Uncategorized 
©Always Q Uncategorized 



3. In the right pane, select the Enable check box for Blue Web Filter. 

4. Click Apply. 

5. Continue with the next section. 



For more information about other options, including lookup mode and 
memory allocation, click Help or see the section on setting the memory 
allocation in Chapter 2, Filtering Web Content, in Volume 7: Managing Content. 
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Setting up the BCWF Database Download 

The Blue Coat Web Filter database must be updated at least once every 30 days. 
You have the option of updating the database automatically or at a time range you 
select. This section discusses how to update the database automatically. 

To set up the BCWF database download: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Click Configuration > Content Filtering > Blue Coat > Blue Coat Web Filter. 

3. On the Blue Coat Web Filter tab page, enter the following information: 



Option 


Description 


Username field 


Enter the user name provided with your BCWF 
subscription. 


Change Password button 


Click the button and follow the prompts on 
your screen to set or change your BCWF 
password. 


URL field 


Enter the URL provided with your BCWF 
subscription. Typically, the URL is: 
https://list.bluecoat.com/bcwf/activity/ 
download /bcwf .db 


Set to default button 


Click to reset the URL field to its default value 

of https : //list .bluecoat . com/bcwf / 
activity/download/bcwf . db 



4. Click Download Now. 



This starts the download process. Make sure you verify the download was 
successful as discussed in the next step. 

5. Allow a few minutes for the download to complete and click Verify Download. 
The following table shows sample success messages. 



Type of download 


Success message 


Full database 


Blue Coat download at: 2008/07/16 19:25:29 - 
0500 

Downloading from https://list.bluecoat.com/ 

bcwf /activity/ down load/ bcwf . db 

Requesting initial database 

Download size: 170228642 

Database date: Wed, 16 Jul 2008 04:06:30 

UTC 

Database expires: Fri, 15 Aug 2008 04:06:30 

UTC 

Database version: 200819804 

Database format: 1.1 
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Type of download 


Success message 


Differential update 


Blue Coat download at: 2008/07/16 14:16:19 - 
0500 

Downloading from https://list.bluecoat.com/ 

bcwf /activity/download/bcwf . db 

Requesting differential update 

Differential update applied successfully 

Download size: 170228642 

Database date: Wed, 16 Jul 2008 04:06:30 

UTC 

Database expires: Fri, 15 Aug 2008 04:06:30 

UTC 

Database version: 200819804 

Database format: 1.1 



The following table shows sample error messages with suggestions about how to 
correct the error. 



Failure message 


Suggested workaround 


ERROR: Socket connect 
error 


The Client Manager cannot contact the BCWF URL, 
most likely for any of the following reasons: 

• The URL is incorrect 

Click Configuration > Content Filtering > Blue Coat 

and verify the value of the URL field with the 
information provided with your Web filtering license. 
Try clicking Set to default and trying the download 
again. 

• Network issues prevent the Client Manager from 
reaching the site. 

Log in to the Client Manager's CLI and enter the 
following command: 

> ping list.bluecoat.com 

If you cannot ping the list . bluecoat . com Web site, 
check the configuration of routers and firewalls to 
make sure the Client Manager can reach the site. 


ERROR: HTTP 401 - 
Unauthorized 


Either the user name or password you specified is 
incorrect. 

Click Configuration > Content Filtering > Blue Coat and 

verify the value of the Username field. Click Change 
Password and enter your password again in the 
provided fields. 
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For more information about other options, click Help or see the section on 
configuring Blue Coat Web filter in Chapter 2, Filtering Web Content, in 
Volume 7: Managing Content. 

1. Select the Automatically check for updates check box. 

2. Click Apply. 

3. Continue with the next section. 

Enabling Other Databases 

Although it is possible to enable other databases (for example, Internet Watch 
Foundation), categories in these databases are not used by ProxyClient Web 
filtering. Categories from only the following sources are used by the ProxyClient: 

□ The BCWF database 

□ The local database 

□ Policy, such as VPM policy 

□ System categories (none and unavailable), which cannot be edited or deleted 

□ The Default category, which enables you to allow or block any content request 
that is not classified into any of the preceding categories 

The tasks required to use categories from these sources are discussed in the 
following sections. 

Enabling the Use of the Local Database (Optional) 

The local database can be used by administrators to set up whitelists or blacklists; 
in other words, it enables you to add categories with particular URLs that you can 
allow, block, or warn. 

If you do not wish to enable the local database, skip this section and continue with 
"Enabling ProxyClient Web Filtering" on page 238. 

This section discuses the following topics: 

□ "Creating the Local Database" 

□ "Enabling the Local Database" on page 237 

Creating the Local Database 

To create the local database: 

1. Create a text file in the following format: 

define category-name 

urll 

url2 

urln 

end 
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define category-name 

urll 

url2 

urln 

end 

For example, 

define category whitelist 
www . cnn . com 
www . webmd . com 
end 

define category blacklist 

www . gambl ing . com 

end 

Each category can have an unlimited number of URLs. 

2. Upload the text file to a Web server that the Client Manager can access. 

3. Continue with the next section. 

Enabling the Local Database 

To enable the local database: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Click Configuration > Content Filtering > General. 

3. In the right pane, select the Enable check box next to Local Database. 

4. Click Apply. 

5. Continue with the next section. 

Uploading the Local Database to the Client Manager 

To upload the local database to the Client Manager: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Click Configuration > Content Filtering > Local Database. 
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3. In the right pane, enter or edit the following information: 



Option 


Description 


Username field 


Enter the user name required to access the local 
database, if any. 


Change Password button 


Click the button and follow the prompts on 
your screen to set or change your local database 
password. 


URL field 


Enter the URL to the local database. 



4. Click Download Now. 

5. To verify the download, click Verify Download. 

6. Select the Automatically check for updates check box. 

7. Click Apply. 

8. Continue with the next section. 

See Also 

Section on configuring the local database in Chapter 2, Filtering Web Content, in 
Volume 7: Managing Content 

Enabling ProxyClient Web Filtering 

This section discusses how to enable ProxyClient Web filtering on the Client 
Manager. 

To enable ProxyClient Web filtering: 

1. Complete the following prerequisite tasks: 

a. "Designating a ProxySG as the Client Manager" on page 210 

b. "Enabling Blue Coat Web Filtering" on page 233 

2. Log in to the Client Manager's Management Console as an administrator. 

3. Click Configuration > ProxyClient > Web Filtering > Policy. 
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4. Verify the status of Web Filtering License is valid. 

If another status displays (such as invalid), perform the following tasks on 

Configuration > Content Filtering > Blue Coat > Blue Coat Web Filter: 

• Verify that the value for Username is correct. 

• Click Change Password and enter the password provided with your BCWF 
license in the provided fields. 

• Optional. Click Set to default to set the value of the download URL to its 
default value. 

5. If you have a valid Web filtering license, select the Enable Web Filtering check 
box. 

6. Click Apply. 

If that does not resolve the problem, download the database manually as 
discussed in steps 4 and 5 in "Setting up the BCWF Database Download" on 
page 234. 

7. After you have successfully enabled the BCWF database with a valid license, 
continue with the next section. 

See Also 

Chapter 2, Filtering Web Content, in Volume 7: Managing Content 



239 



Volume 5: Advanced Netzvorking 



Section C: Configuring the ProxyClient 

Assigning Policy Actions to Content Categories 

You define content policy by selecting categories and corresponding policy 
actions that either allows the content, blocks the content, or warns users that 
accessing content might violate company Web use policies. 

This section discusses the following topics: 

□ "Getting Started With Categories" 

□ "Selecting Categories" on page 241 

□ "Managing Policy Categories" on page 242 

□ "Selecting Policy Actions for Categories" on page 244 

□ "Configuring System and Default Policy Actions" on page 246 

□ "Ordering Categories in the Rulebase" on page 247 

□ "Configuring Other Web Filtering Options" on page 250 

If you are configuring ProxyClient Web filtering for the first time, you should 
complete the tasks discussed in the preceding sections in the order in which they 
are shown. If you are modifying an existing configuration, choose any task. 

Getting Started With Categories 

This section discusses how to locate the available categories so you can get started 
defining categories and their associated policy actions. 

To implement Web filtering policy for ProxyClient users: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Click Configuration > ProxyClient > Web Filtering > Policy. 

On the Policy tab, the All Categories section displays 
the available category nodes: 

• Blue Coat: The BCWF database. 

• Local: The local database, which is discussed in 
"Enabling the Use of the Local Database 
(Optional)" on page 236. 

• System: Special categories (none and unavailable) that are discussed in 
more detail in Step 4 on page 246. 

• Policy: Categories defined using policy (usually the Visual Policy Manager 
(VPM)). 



All Categories: 

B Categories 
E) Blue Coat 
E} Local 
S System 
E) Policy 
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Note: 

• If you are not familiar with ProxySG content filtering, refer to 
Chapter 2, Content Filtering, in Volume 7: Managing Content of the 
Blue Coat ProxySG Configuration and Management Suite. 

• Many Web sites generate more than one URL request so it is 
possible that an allowed Web site might create other URL 
requests that are categorized differently, or are categorized as the 
System category none. 

For example, images and advertisements displayed on an 
allowed Web site are individually classified based on their URLs. 
Even if you allow users to access that Web site, each of the ads 
and images on the site can be blocked based on each URL's 
categorization. 



3. Continue configuring Web filtering. 

If you are configuring ProxyClient Web filtering for the first time, complete 
following tasks in the order in which they are presented. If you have already 
configured Web filtering and need to modify your previous choices, choose a 
task from the following list. 

• "Selecting Categories" 

• "Configuring System and Default Policy Actions" on page 246 

• "Selecting Policy Actions for Categories” on page 244 

• "Ordering Categories in the Rulebase" on page 247 

• "Configuring Other Web Filtering Options" on page 250 

Selecting Categories 

This section discusses how to select categories to use when filtering Web content 
for ProxyClient users. Select only the categories you wish to explicitly allow, deny, 
or warn users about accessing. 

If a user accesses content that is not associated with any categories you select, the 
policy action for the Default category is applied. For more information about the 
Default category, see "Configuring System and Default Policy Actions" on page 
246. 

To select categories: 

1. Complete the tasks discussed in the following sections first: 

• "Enabling Blue Coat Web Filtering" on page 233 

• Optional. "Enabling the Use of the Local Database (Optional)" on page 236 

• "Enabling ProxyClient Web Filtering" on page 238 

2. In the Client Manager's Management Console, click Configuration > ProxyClient 
> Web Filtering > Policy. 
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3. In the All Categories pane, expand Blue Coat. 



Note: If the Client Manager does not have a valid BCWF database, the 
BCWF categories do not display. If the database is stale (not updated in 
the last 30 days), the categories are unavailable. Both of these symptoms 
indicate a BCWF license issue. For more information, see one of the 
following: 

• "Configuring ProxyClient Web Filtering" on page 231 

• Chapter 2, Web Filtering, in Volume 7: Managing Content 

4. Select the check box next to each category to enforce a policy action on that 
category. 

When you select a category, it automatically displays in the Selected Category 
Rulebase pane with a policy action the opposite of the Default category. 

5. Repeat the preceding steps for the local and policy categories. 

If you have no policy categories defined, see the next section. 

If you do not wish to configure or change your policy categories, skip the next 
section and continue with "Selecting Policy Actions for Categories" on page 
244. 

Managing Policy Categories 

This section discusses how to add or edit policy categories. If an administrator has 
already configured policy categories using VPM, you can add, edit, delete, or edit 
URLs in any configured category. If you do not already have policy categories, 
you can add them. 

For more information about using VPM to add categories, see Volume 6: The Visual 
Policy Manager and Advanced Policy. 

To add, edit, delete, or edit URLs in policy categories: 

1. Complete the tasks discussed in the following sections first: 

• "Enabling Blue Coat Web Filtering" on page 233 

• "Enabling the Use of the Local Database (Optional)" on page 236 

• "Enabling ProxyClient Web Filtering" on page 238 

• "Getting Started With Categories" on page 240 

2. In the Client Manager's Management Console, click Configuration > ProxyClient 
> Web Filtering > Policy. 

3. Near the bottom of the right pane, click Edit Categories. 

The Edit Categories dialog displays the currently configured category nodes 
(for example. Policy, Local, Blue Coat, and System). 
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Note: You can manage only the Policy categories. With the exception of local 
categories (that come from the local database, if it is configured), the other 
categories cannot be changed. 



4. In the Edit Categories dialog, expand Policy. 

5. You have the following options: 



Task 


Procedure 


Add a policy category 


1. Click Policy. 

2. Click Add. 

3. In the Object Name dialog, enter a name for 
the policy category. 

4. Click OK. 

5. Add URLs to the category as discussed in 
later in this table. 


Rename a policy category 


1. Click the name of the category. 

2. Click Rename. 

3. In the Edit Locally defined category Object 
dialog, enter a new name for the policy 
category. 

4. Click OK. 

5. Optionally add URLs to the category as 
discussed in later in this table. 


Delete a policy category 


1. Click the name of the category. 

2. Click Remove. 

You are required to confirm the deletion. 


Edit the list of URLs in a policy 
category 


1. Click the name of the category in which you 
want to edit the list of URLs. 

Note: You cannot add URLs to the Policy 
node. You must first create a category under 
that node as discussed earlier in this table. 

2. Click Edit URLs. 

3. In the Edit Locally defined category Object 
dialog, enter or edit the list of URLs, one 
URL per line. 

4. Click OK. 



6. In the Edit Categories dialog, click OK. 

7. Continue with the next section. 
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Selecting Policy Actions for Categories 

After choosing content categories, you must assign a policy action to each 
category You have the following options: 

□ If the policy action is allow, the request goes to its destination. 

□ If the policy action is block, the blocked category exception page displays. 

□ If the policy action is warn, a warning message displays. 

The user must click an acceptance link, which represents an acknowledgment 
that the content request might violate corporate Web use policy. If the user 
clicks the acceptance link, the request goes to its destination. 

Note: If a user clicks the acceptance link the requested Web site will be 
accessible for 15 minutes. The accessibility time period is not currently 
configurable for the Web site. 

To select policy actions: 

1. Complete the tasks discussed in the following sections first: 

• "Enabling Blue Coat Web Filtering" on page 233 

• "Enabling the Use of the Local Database (Optional)" on page 236 

• "Enabling ProxyClient Web Filtering" on page 238 

• "Getting Started With Categories" on page 240 

• "Selecting Categories" on page 241 

2. In the Client Manager's Management Console, click Configuration > ProxyClient 
> Web Filtering > Policy. 

3. In the Selected Category Rulebase section, select a policy action for each category 
you added. 

The following table discusses the available policy actions. 

For detailed information about the exception page that displays in the user's 
Web browser for the block and warn policy actions, see "Displaying and 
Customizing Web Filtering Exception Pages" on page 253. 



Policy action 



Example 



Block: Users are denied this content; an 



access log entry occurs; the user receives an 
exception page notifying their breach of 
Web use policy. 



Selected Category Rulebase: 



Categories 


Action 


Adult/Mature Content 


Block 


V 


Pornography 


Block 


V 


Intimate Apparel/Swimsuit 


Block 


V 


Nudity 


Allow 


V 


Gambling 


lAllow 


Financial Services 


Block ^ 


Search Engines/Portals 


|Warn | 


Default 


Allow 
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Policy action 

Allow: Users are allowed this content; an 
access log entry occurs for URL tracking 
and analyzing Web use (if the value of Log 
Exceptions Only on the Configuration > 
ProxyClient > Web Filtering > Log tab page is set 
to All). 



Warn: An access log entry occurs; an 
exception page displays in the user 's Web 
browser notifying the user this Web 
content might violate Web use policy; the 
user must click a displayed link to 
acknowledge this browsed category before 
proceeding (or they can opt out). 

Note: If a user clicks the acceptance link the 
requested Web site will be accessible for 15 
minutes. The accessibility time period is not 
currently configurable for the Web site. 



Example 



Selected Category Rulebase: 



Categories 


Action 




Adult/Mature Content 


Block 


V 


Pornography 


Block 


V 


Intimate Apparel/Swimsuit 


Block 


V 


Nudity 


Block 


V 


Gambling 


Block 


V 


Financial Services 




rz 


Search Engines/Portals 


Allow 




Default 


Allow 


V 


1 1 



Selected Category Rulebase: 



Categories 


Action 




Adult/Mature Content 


Block 


V 


Pornography 


Block 


V 


Intimate Apparel/Swimsuit 


Block 


V 


INudity 


Block 


V 


Gambling 


Block 


V 


Financial Services 


Allow 


V 


Search Engines/Portals 


Allow 


V 


Default 


Allow 






Block 






Warn ^ 



4. Continue with the next section. 



If you have already defined policy actions for the system and default 
categories, continue with "Ordering Categories in the Rulebase" on page 247. 
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Configuring System and Default Policy Actions 

This section discusses how to configure policy actions for the following 
categories: 



Category 


Description 


System 


The System node contains the following categories, which cannot be edited or 
deleted: 

• none, a category for Web sites that are not rated in any available categories and 
for which the DRTR could not determine a rating. Available categories mean 
BCWF database categories, local database categories (if enabled), and policy 
categories (if configured). 

Many Web sites generate more than one URL request so it is possible that an 
allowed Web site might create other URL requests that are categorized 
differently, or are categorized as none. 

For example, images and advertisements displayed on an allowed Web site are 
individually classified based on their URLs. Even if you allow users to access 
that Web site, each of the ads and images on the site can be blocked based on 
each URL's categorization. 

• unavailable, a category that is used if all of the following are true of a 
particular URL request: 

• When a service point cannot be reached 

• When there is no match either in the local database (if enabled) or policy 
categories (if configured) 


Default 


The Default category always displays as the last entry in the Category Rulebase 
section. The policy action for the Default category is used if a URL request is not 
classified into any of the categories in the Category Rulebase section. 

Use caution before setting the policy action of the Default category to block. If 
Default is set to block, any URL that is not in a category that you specifically allow 
will be blocked. 



To configure the System categories and the Default category: 

1. Complete the tasks discussed in the following sections first: 

• "Enabling Blue Coat Web Filtering" on page 233 

• "Enabling the Use of the Local Database (Optional)" on page 236 

• "Enabling ProxyClient Web Filtering" on page 238 

• "Getting Started With Categories" on page 240 

• "Selecting Categories" on page 241 

2. In the Client Manager's Management Console, click Configuration > ProxyClient 
> Web Filtering > Policy. 

3. In the All Categories pane, expand System. 

4. Select the check box next to the none or unavailable categories. 
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The following table discusses the meanings of policy actions for these 
categories. 



System category 


Policy action description 


none 


Set the policy action for Web sites that could not be 
categorized by the service point. 


unavailable 


Set the policy action for Web sites for which the 
ProxyClient could not reach a service point, or the 
service point could not reach BCWF, to determine a 
categorization. 



5. When you are satisfied with your policy configuration, select the Enable Web 
Filtering check box. 



6. Click Apply. 

7. In the Selected Category Rulebase pane, choose a policy action for the Default 
category. 



Note: The Default category cannot be moved from the bottom position because 
this category is intended to be used if no other category matches result. 



8. Click Apply. 

9. Continue with the next section. 

Ordering Categories in the Rulebase 

After you have added categories to the rulebase and selected policy actions for 
each, you must consider how the categories are ordered. Many URLs are 
classified in more than one category, which results in a conflict. 

In the case of a conflict between policy actions, the policy action associated with 
the first rulebase match is applied. 

For example, suppose the same URL (www . example . com/news) is listed in two 
categories. One category has a policy action of allow and the other category has a 
policy action of block. 

In the table that follows, www. example . com/news is in both the Blogs/Personal 
Pages and News /Media categories. The following table shows how the conflict is 
resolved. 
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Rulebase configuration 



Policy action 

Because News /Media is first in the 



Selected Category Rulebase: 




rulebase and its policy action is allow, 

www . example . com/news is allowed. 



Move-Up Move-Down 



Promote to 



Top 



Demote to Bottom 



Selected Category Rulebase: 
Categories 



Action 



Blogs/Personal Pages 


- 1 


News/Media 


Allow 


Default 


Allow 



Move-Up 



Move-Down 



Promote to Top 



Demote to Bottom 



Because Blogs /Personal Pages is first in 
the rulebase and its policy action is 

block, www . example . com/news is 

blocked. 



Note: If the user is in an office location with ProxyClient Web filtering 
disabled, a branch ProxySG performs Web filtering. For more information 
about configuring a branch ProxySG to perform Web filtering, see Volume 7: 
Managing Content. 



Blue Coat recommends you order Web filtering rules in the category rulebase as 
follows: 

1. Whitelist overrides (that is, local database and policy categories you always 
want to allow) 

2. Blacklist overrides (that is, local database and policy categories you always 
want to block) 

3. All other categories with policy action set to block 

4. All other categories with policy action set to warn 

5. All other categories with policy action set to allow 
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To order categories in the category rulebase: 

1. Complete the tasks discussed in the following sections first: 

• "Enabling Blue Coat Web Filtering" on page 233 

• "Enabling the Use of the Local Database (Optional)" on page 236 

• "Enabling ProxyClient Web Filtering" on page 238 

• "Getting Started With Categories" on page 240 

• "Selecting Categories" on page 241 

• "Configuring System and Default Policy Actions" on page 246 

• "Selecting Policy Actions for Categories" on page 244 

2. In the Client Manager's Management Console, click Configuration > ProxyClient 
> Web Filtering > Policy. 

3. In the Category Rulebase pane, click the name of a category to move. 

4. Click one of the following buttons: 



Button 


Meaning 


Move-Up 


Move the selected category up one position in the 
rulebase. Use this button to move a more restrictive 
category and action before a less restrictive category 
and action. 


Move-Down 


Move the selected category down one position in the 
rulebase. Use this button to move a more general 
category and action after a more restrictive category 
and action. 


Promote to Top 


Move the selected category and action to the top of the 
rulebase. Use this button to move a very specific 
category and action to the top of the rulebase. 


Demote to Bottom 


Move the selected category and action to the bottom of 
the rulebase. (The Default category is always the last 
category in the rulebase; this button demotes the 
selected category to a position immediately above 
Default.) 



5. Continue with the next section. 

If you have already configured options for license expiration, HTTPS filtering, 
and safe search, continue with one of the following sections: 

• "Web Filtering Best Practices" on page 251 

• "Displaying and Customizing Web Filtering Exception Pages" on page 253 

• "Enabling Web Filtering Logging" on page 256 
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Configuring Other Web Filtering Options 

This section discusses how to configure the following options: 

□ On license expiration, which sets the behavior of ProxyClient Web filtering in 
the event the BCWF license expires on the Client Manager 

□ HTTPS filtering, which determines whether or not Web filtering policy actions 
are applied to HTTPS content 

□ Safe search, which determines whether or not ProxyClient users are required 
to use safe search with supported search engines. 

To configure other Web filtering options: 

1. Complete the tasks discussed in the following sections first: 

• "Enabling Blue Coat Web Filtering" on page 233 

• "Enabling the Use of the Local Database (Optional)" on page 236 

• "Enabling ProxyClient Web Filtering" on page 238 

• "Getting Started With Categories" on page 240 

• "Selecting Categories" on page 241 

• "Configuring System and Default Policy Actions" on page 246 

• "Selecting Policy Actions for Categories" on page 244 

2. In the Client Manager's Management Console, click Configuration > ProxyClient 
> Web Filtering > Policy. 

The bottom portion of the Policy tab page displays. 



Edit Categories | On License Expiration: 

I - Enforce Safe Search I - Enable HTTPS Filtering 



Editing categories is not discussed in this section; for more information, see 
"Managing Policy Categories" on page 242. 

3. Enter or edit the following information: 




Option 


Description 


On License Expiration list 


Select the action to take if the BCWF license expires 
(usually because the database has not been updated 
in a 30-day period): 

• Fail Open — Users are allowed to browse 
anywhere; in other words, content is not filtered. 
Select this option if user Web access is more 
critical than filtering or security. 

• Fail Closed — Users are not allowed to browse to 
any Web page. A Service Unavailable exception 
displays in the user 's Web browser. Select this 
option if security is your primary concern. 
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Option 


Description 


Enable HTTPS Filtering check 
box 


Select this check box to use Web filtering when the 
content request is sent over an SSL connection using 
the default port 443. For exceptions to this behavior, 
see the ProxyClient Release Notes. 

Clear this check box to not filter HTTPS traffic if 
certain browsers are used. 


Enforce Safe Search check box 


Select this check box to force a search engine that 
supports Safe Search to enable its strictest search 
filter; however, the quality of the filtering is based 
on the search engine's built-in capabilities. The same 
search string entered on one search engine might 
yield different results when entered on another 
search engine (including returning varying levels of 
inappropriate content). 

Safe Search is supported on the following search 
engines: A9, Altavista, MSN /Live, Google, Yahoo, 
ASK, Earthlink, and Orange.co.uk. 

With safe search enabled, the search engine Web 
page displays Safe Search ON, Family Filter On, 
Safe Search Strict, or another engine-specific string. 
Clear this check box if you do not wish to enforce 
Safe Search. 



See Also 

"About ProxyClient Web Filtering" on page 196 
"Web Filtering Best Practices" on page 251 

"Displaying and Customizing Web Filtering Exception Pages" on page 253 
"Enabling Web Filtering Logging" on page 256 
"Configuring ProxyClient Web Filtering (CLI)" on page 264 

Web Filtering Best Practices 

Blue Coat recommends the following best practices when configuring 
ProxyClient Web filtering: 

□ If you have mobile users who frequently stay in hotels or access networks that 
require an initial guest login before getting Internet access, select the System > 
unavailable category and set it to Allow. For more information about this 
scenario, see "About Security With Guest User Scenarios" on page 204. 

□ Some software update sites will be blocked if the Business /Economy category 
is set to Block or Warn. 

For example, Java updates would fail because the Java update site is rated as 
Business /Economy. Either allow the Business /Economy category or add the 
software update Web sites to a custom category (using either the local 
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database or VPM), set its policy action to Allow, and order the rule before the 
the Business /Economy category 

□ Because a particular URL might be listed in more than one category, policy 
action conflicts can occur. 

In the case of a conflict between policy actions, the policy action associated with 
the first rulebase match is applied. 

For example, suppose the same URL (www . example . com/news) is listed in two 
categories. One category has a policy action of allow and the other category has a 
policy action of block. 

In the table that follows, www. example . com/news is in both the Blogs/Personal 
Pages and News /Media categories. The following table shows how the conflict is 
resolved. 



Rulebase configuration 



Policy action 

Because News /Media is first in the 



Selected Category Rulebase: 




rulebase and its policy action is allow, 

www . example . com/news is allowed. 



Move-Up Move-Down 



Promote to 



Top 



Demote to Bottom 



Because Blogs /Personal Pages is first in 
the rulebase and its policy action is 

block, www . example . com/news is 

blocked. 



Promote to Top 




Demote to Bottom 





Selected Category Rulebase: 
Categories 



Action 



News/Media 


Allow 


Default 


Allow 



Move-Up 



Move-Down 



Note: If the user is in an office location with ProxyClient Web filtering 
disabled, a branch ProxySG performs Web filtering. For more information 
about configuring a branch ProxySG to perform Web filtering, see Volume 7: 
Managing Content. 
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Blue Coat recommends you order Web filtering rules in the category rulebase as 
follows: 

1. Whitelist overrides (that is, local database and policy categories you always 
want to allow) 

2. Blacklist overrides (that is, local database and policy categories you always 
want to block) 

3. All other categories with policy action set to block 

4. All other categories with policy action set to warn 

5. All other categories with policy action set to allow 

Displaying and Customizing Web Filtering Exception Pages 

Am exception page is an HTML message that displays in a user's Web browser 
when a content request triggers a policy action. You have the option of editing the 
default exception pages to provide more detail about why the category is blocked. 



Note: The behavior of exception pages when the user is browsing HTTPS content 
when HTTPS filtering is enabled is as follows: 

• Some Web browsers: The exception page displays in the same browser 
window as the request. 

• All other Web browsers: The exception page displays in a new browser 
window. 

For more information, see: 

• For up-to-date information about Web browsers and their behavior with 
HTTPS filtering, see the ProxyClient Release Notes. 

• To enable HTTPS filtering, in the Client Manager's Management Console, 
click Configuration > ProxyClient > Web Filtering > Policy, and select the Enable 
HTTPS Filtering check box. Click Help for more information. 



Blue Coat provides default exception pages for the following occurrences: 

□ Blocked content: When a user requests content that violates (matched by 
category) enterprise Web use policy, the following message displays in the 
Web browser: 

Your request was denied because of its content categorization: 
Category: offending_category_name 
URL: requested_URL 
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□ Warn: When a user requests content that might violate enterprise Web use 
policy (for example, you chose a policy action of Warn for the Search Engine/ 
Portals category, and you want to coach a user regarding Web use policies), 
the following message appears in the browser: 

It may violate company policy to visit this site. 

Category: Search Engine/Portals 

URL: www.google.com 

Click here to continue anyway. 

The last line, available only (by default) on the Warn exception page, is a link 
that users click to acknowledge the warning and proceed with the content 
request. If they elect to opt out of this request, they must navigate to another 
page, click the Back button on the browser, or exit the browser. 

□ Unavailable rating service: If a user is logged in remotely, requests a URL that 
is not already categorized, and ProxyClient cannot connect to a content rating 
service, the following message displays in the browser: 

The Blue Coat Web Filter Service point could not be reached. This 
may be due to a networking error. 

Users are not allowed to retrieve Web content until a rating service is reached 
(unless the System > unavailable category is set to Allow). 

If you decide to change or add to the default text, each exception page is 
customizable using the Management Console or the command line. 

To customize exception pages: 

1. Log in to the Client Manager's Management Console as an administrator. 

2. Click Configuration > ProxyClient > Web Filtering > Exceptions. 



3a 



Policy 

Exceptions 

Exception page for: 
1 

|</TABLE> 

<BR> 



Exceptions 



Log 



Warn 

-(Block 



Unavailable 



<A HREF="$ (override-url 

|<BR> 

<BR> 

Contact your network su' 
<BR> 

<A I D = " MORE_ INF 0_L INK " 
<DIV ID= "MORE INFO" STY 




Substitution Variables: 
url 

cs-categories 

|cs-categories-exception 

override-url 
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3. Customize exception pages: 

a. From the Exception page for list, select a page to customize: 

• Block: Display text when a user browses to content blocked by policy 

• Warn: Display text to inform users that the content they are requesting 
might violate Web use policy Users must click a link to acknowledge 
this warning before receiving the content. 

• Unavailable: Display text when the rating service becomes unavailable. 

b. Customize the Web page header and body text. The Substitution 

Variables field provides variables you can insert to display content 

information: 

• url: Displays the requested URL. 

• cs-categories: A full list of all category rating assigned to the Web site. 
Many Web sites have more than one rating. 

• cs-categories-exception: The category that caused the exception (the first 
one matched in the rulebase). 

• override-url: Applies to the Warn exception page only. This is used if 
you change the continue anyway link to something else, such as a 
button. It will be substituted with the URL that must be pulled 
through an HTML request to visit the page that was blocked by the 
exception. 

To add a variable to the custom message, insert the cursor in the HTML 

code where you want the variable to be, select a variable, and click Insert. 

You can add as many variables as you want. 

c. Click Apply. 
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Enabling Web Filtering Logging 

This section discusses Web filtering logging in the following sections: 

□ "About Web Filtering Logging" 

□ "How to Enable Web Filtering Logging" on page 256 

□ "Interpreting the Log Files" on page 259 

About Web Filtering Logging 

Analyzing user Web browsing activity allows you to better customize your 
content filter policies and to verify that your users are abiding by company 
policies. You can configure the ProxyClient to upload user Web browsing activity 
logs to an anonymous FTP server at regular time intervals or when the local log 
file reaches a specified size. 

Connections occur only when the client system has access to the specified FTP 
server, which is typically when the user connects to the corporate network. 



Note: Because log files are uploaded using anonymous FTP, Blue Coat strongly 
recommends you put your FTP server behind the corporate firewall. In addition, 
you should configure the FTP server to disable scans and file overwrites. 

Placing an FTP server outside the firewall has the advantage that even mobile 
users can upload log files to it; however, it exposes the server and your company 
to potentially serious malicious activity. 



How to Enable Web Filtering Logging 

This section discusses how to enable Web filtering logging. You need to know the 
name of the anonymous FTP server to which to upload files and the directory to 
which to write the files. You can also configure automatic upload options based 
on configurable thresholds. 

If the user exceeds either of the following configurable thresholds, log updates 
occur as soon as possible: 

□ Number of hours since the last upload 

□ Number of MB required for log files on the user's computer 

To enable logging and configure logging options: 

1. Log in to the Client Manager's Management Console as an administrator. 
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2. Click Configuration > ProxyClient > Web Filtering > Log. 

The Log tab page displays. 



Policy Exceptions Log 

[v^l Enable Logging 
® Log All 



O Log Exceptions Only 

r FTP Server Connection 



Settings for: 
Hosts: 

Path: 



Primary FTP Server v 


ftp://192.168. 5. 5 


Port: 21 


MobileUserLogs/December07/ 





Anonymous FTP Server will be used for logging 



- Upload Settings 



Upload periodically every 

Start an early upload if log reaches 




Hours 

megabytes 



jo Min 



3. Select the Enable Logging check box. 

4. Click one of the following logging options: 



Option 


Description 


Log All 


Log all Web browsing activity. 


Log Exceptions Only 


Add a log entry only when a policy exception occurs 
(blocks, warnings, and rating service unavailability). 
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5. In the FTP Server Connection section, enter or edit the following information: 



Option 


Description 


Settings for list 


Click the type of host you are configuring: 

• Primary FTP Server 

• Alternate FTP Server 


Hosts field 


Enter the FTP server's fully-qualified domain name 
or IP address. 


Port field 


Enter the FTP server's listen port. The default is port 
21. Make sure your firewall allows FTP traffic 
through this port, and change the port from the 
default only if your firewall and FTP server are 
configured accordingly. 


Path field 


Enter the relative path on the server to write the 
access log files. 



6. Choose options that determine when files are uploaded from the ProxyClient 
computer to the FTP server. 



You can choose either a time interval or the total size, in MB, files occupy on 
the client computer. This setting is particularly useful for mobile or offsite 
users that cannot connect to your FTP server. 

If a mobile or offsite user is away from the network for an extended period of 
time and the threshold values are exceeded, an upload occurs as soon as 
possible. 
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Enter or edit the following information: 



Option 


Description 


Upload periodically every 


• Hours field: Enter the maximum number of hours 
to wait before attempting to upload logs from the 
ProxyClient computer to the FTP server. 

• Minutes field: Enter the maximum number of 
minutes to wait before attempting to upload logs 
from the ProxyClient computer to the FTP server. 
Note: If you enter a non-zero value for both Hours 
and Minutes, the total amount of time is used. For 
example, if you enter 24 Hours and 10 Minutes, the 
client waits 24 hours and 10 minutes to upload log 
files. 


Start an early upload if log 
reaches 


Enter the minimum log file size, in megabytes, to 
trigger a log file upload. 

This value takes precedence over the value you 
entered in the preceding field. In other words, if you 
specify 24 hours in the preceding field and 1 0 
megabytes in this field, if the client log file size 
reaches 10 megabytes after only 10 hours, the 
ProxyClient attempts to upload its log files to the FTP 
server. 



7. Click Apply. 



Interpreting the Log Files 

The log file starts similarly to the following: 

#Software:SG Client 3. 1.1.0 
#Version : 1 . 0 

#Fields : datetime c-ip c-username x-cs-auth-domain c-computername x- 
except ion- ides -categoriescs-categories-exception cs-referer cs -method 
cs-uri-schemecs-hostcs-uri-port cs-uri-path cs-uri-query cs-uri- 
extensioncs -user-agents- ip 

The following table defines the fields used in the log: 



Field 


Description 


date 


Date in Universal Time Code (UTC) format. 


time 


Time stamp in UTC format. 


c-ip 


Client's IP address. 


c-username 


Client's login user name. 


x-cs-auth-domain 


Client's domain name (if available). 


c-computername 


Client's computer name. 
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Field 


Description 


x-exception-id 


One of the following: 

• - if the content is allowed. 

• content filter warned if the policy action is 
warn. 

• content filter denied if the policy action is 
block. 


cs-categories 


Semi-colon-delimited categories for the content 
request. 


cs- categories -except ion 


The first category match; in other words, the 
category on which the policy action shown by x- 

exception-id is based. 


cs-referer 


Referring URL, if any. 


cs-method 


The method used in the content request (for 
example, GET). 


cs-uri- scheme 


The URI's schema (http or https). 


cs-host 


The host portion of the URL 


cs-uri-port 


The port used to access the URI. 


cs-uri-path 


The path relative to cs-host. If cs-uri-scheme is 
https, this field is blank. 


cs-uri -query 


Query string, if any. If cs-uri-scheme is https, this 
field is blank. 


cs-uri-extension 


File extension of the object. 


cs-user-agent 


Information about the Web browser that requested 
the object. 


s-ip 


Web server's public IP address. 



Following is a sample log entry showing that content was blocked: 

2008-07-3117:51:17-joe.j ones USA-TX-Austin LT-JOEJONES 

content_f ilter_denied"Vehicles" "Vehicles" -GET /http www.mazdausa.com 
80 / --Mozilla/4 . 0 (compatible; MSIE 7.0; Windows NT 5.1; .NET 

CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)129.33.107.81 

In the preceding example, user j oe . j ones requested content from http : // 
www.mazdausa.com and the content was blocked. The content was categorized as 
vehicles, was requested by Internet Explorer 7, and was delivered from a Web 
server with public IP address 129. 33. 107.81. 



260 



Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient) 



Section C: Configuring the ProxyClient 

Configuring the ProxyClient from the Command Line 

This section includes the following topics: 

□ "Setting the Client Manager (CLI)" on page 261 

□ "Configuring General ProxyClient Settings (CLI)" on page 261 

□ "Configuring ProxyClient ADN Manager Settings (CLI)" on page 262 

□ "Configuring ProxyClient ADN Rules Settings (CLI)" on page 262 

□ "Configuring ProxyClient Locations (CLI)" on page 262 

□ "Configuring ProxyClient File Sharing (CIFS) Settings (CLI)" on page 263 

□ "Configuring ProxyClient Web Filtering (CLI)" on page 264 

□ "Loading the Software (CLI)" on page 264 

□ "Showing ProxyClient Settings (CLI)" on page 265 

Setting the Client Manager (CLI) 

For more information about configuring the Client Manager, see "Designating a 
ProxySG as the Client Manager" on page 210. 

To configure the Client Manager: 

1. At the # (config) command prompt, enter proxy-client. 

2. Enable this appliance as the Client Manager: 

# (config proxy-client) enable 

3. Configure Client Manager settings: 

# (config proxy-client) client-manager host { f rom-client-address | 

ip_address \ host } 

# (config proxy-client) client-manager install-port port 
# (config proxy-client) client-manager keyring keyring 



Configuring General ProxyClient Settings (CLI) 

For more information about general client settings, see "Designating a ProxySG as 
the Client Manager" on page 210. 



To configure general client settings: 



1 . 

2 . 



At the # (config) command prompt, enter proxy-client. 



Configure general client settings: 



# (config 

# (config 

# (config 

# (config 



proxy-client) 

proxy-client) 

proxy-client) 

proxy-client) 



max -cache-di sk -per cent percen tage 
software-upgrade-path url 
update-interval minutes 
view 
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Configuring ProxyClient ADN Manager Settings (CLI) 

For more information about client ADN Manager settings, see "Accelerating 
Network Traffic" on page 216. 

To configure client ADN manager settings: 

1. At the # (config) command prompt, enter proxy-client. 

2. At the # (config proxy-client) prompt, enter adn. 

3. Configure ADN manager settings: 

# (config proxy-client acceleration adn) primary-manager ip-address 
# (config proxy-client acceleration adn) backup -manager ip-address 
# (config proxy-client acceleration adn) manager-port plain-port 

Configuring ProxyClient ADN Rules Settings (CLI) 

For more information about client ADN rules settings, see "Accelerating Network 
Traffic" on page 216. 

To configure client ADN rules settings: 

1. At the # (config) command prompt, enter proxy-client. 

2. At the #(config proxy-client) prompt, enter adn. 

3. Configure ADN rules settings: 

# (config proxy-client acceleration adn) port-list { exclude-ports | 
include -ports } 

# (config proxy-client acceleration adn) {exclude-ports | include- 
ports} { port | port-list | port-range } 

# (config proxy-client acceleration adn) exclude- subnets 

# (config proxy-client acceleration adn exclude-subnets ) {add | 
remove} s ubnet_pre fix [ /prefix length] 

# (config proxy-client acceleration adn exclude-subnets) clear 
# (config proxy-client acceleration adn exclude-subnets) exit 
# (config proxy-client acceleration adn exclude-subnets) view 
# (config proxy-client acceleration adn) exit 

Configuring ProxyClient Locations (CLI) 

For more information about location settings, see "Configuring ProxyClient 
Locations" on page 225. 

To configure client location settings: 

1. At the # (config) command prompt, enter proxy-client. 

2. At the # (config proxy-client) command prompt, enter locations. 
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3. 



Configure location settings: 



#(config proxy-client locations) create location^name 
# (config proxy-client locations) edit location_name 



# (config 

# (config 

# (config 

# (config 

# (config 

# (config 

# (config 

# (config 
# (config 
# (config 
# (config 
# (config 
# (config 

# (config 
# (config 
# (config 

# (config 
# (config 
# (config 

# (config 

# (config 

# (config 



proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 



name) acceleration {enable | disable} 
name) webfilter {enable | disable} 

name dns) add ip-address 

name dns) clear 

name dns) exit 

name dns) remove ip-address 

name dns) view 

name source) add ip-address-range 
name source) clear 
name source) exit 

name source) remove ip-address-range 

name source) view 

name vnic) add vnic-address- range 

name vnic) clear 

name vnic) exit 

name vnic) remove vnic-address-range 
name vnic) view 

name) match-dns {enable | disable} 
name) source {enable | disable} 
name) vnic {enable | disable} 
name) exit 
name) view 



# (config proxy-client locations) 
# (config proxy-client locations) 
# (config proxy-client locations) 
locationname } 

# (config proxy-client locations) 
# (config proxy-client locations) 
# (config proxy-client locations) 



acceleration {disable | enable} 
webfilter {disable | enable} 
{promote location_name | demote 

delete location^name 

clear 

view 



Configuring ProxyClient File Sharing (CIFS) Settings (CLI) 

For more information about CIFS client settings, see "Enabling File Sharing 
Acceleration" on page 221. 



To configure client CIFS client settings: 



1 . 

2 . 

3. 



At the # (config) command prompt, enter proxy-client. 

At the # (config proxy-client) command prompt, enter cifs. 



Configure CIFS settings: 



# (config 

# (config 

# (config 

# (config 

# (config 



proxy-client 

proxy-client 

proxy-client 

proxy-client 

proxy-client 



acceleration 

acceleration 

acceleration 

acceleration 

acceleration 



cifs) 

cifs) 

cifs) 

cifs) 

cifs) 



directory-cache-time seconds 

{disable | enable} 

exit 

write-back {full | none} 
view 
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Configuring ProxyClient Web Filtering (CLI) 

For more information about Web Filtering client settings, see "Configuring 
ProxyClient Web Filtering" on page 231. 



To configure Proxy Client Web Filtering settings: 



1 . 

2 . 

3. 



At the # (config) command prompt, enter proxy-client. 

At the # (config proxy-client) command prompt, enter web-filtering. 



Configure Web filtering settings: 

# (config proxy-client web-filtering) 
# (config proxy-client web-filtering) 
# (config proxy-client web-filtering) 
# (config proxy-client web-filtering) 
category_name | warn category_name} 

# (config proxy-client web-filtering) 
category_name} 

# (config proxy-client web-filtering) 

demote- to-bottom category_name} 

# (config proxy-client web-filtering) 
# (config proxy-client web-filtering) 
# (config proxy-client web-filtering) 

enable} 

# (config proxy-client web-filtering) 
warn} data end-of- file-marker 
# (config proxy-client web-filtering) 
# (config proxy-client web-filteri 
# (config proxy-client web-filteri 
# (config proxy-client web-filteri 
interval hours [ minutes ] 

# (config proxy-client web-filteri 
primary} host hostname port 
# (config proxy-client web-filteri 
exceptions-only } 

# (config proxy-client web-filtering) 



disable 

enable 

default-action {allow | block} 
{allow category_name | block 

{promote category_name I demote 

{promote- to-top category_name | 

failure-mode {open | closed} 
safe-search {disable | enable} 
https-filtering {disable | 

inline exception {block | allow | 

log 

ng log) {disable | enable} 
ng log) early-update megabytes 
ng log) periodic-upload upload- 

ng log) ftp-client {alternate | 

ng log) mode {all-requests | 

view 



Loading the Software (CLI) 

The following commands enable you to upload an updated ProxyClient. car file 
to the Client Manager. 

# (config proxy-client) software-upgrade-path path-to-proxyclient-car 

You can use any of the following commands to load the ProxyClient software on 
the Client Manager: 

# (config) load proxy-client-software 
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Showing ProxyClient Settings (CLI) 

To show current ProxyClient settings: 

#(config) show proxy-client [adn [exclude-subnets ] | clients | cifs | 

locations | web-filtering] 
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Section D: Distributing the ProxyClient Software 

This section discusses the following topics: 

□ "ProxyClient Compatibility with SGOS" 

□ "Overview of Distributing the ProxyClient Software" on page 267 

□ "Preparing Interactive Installations" on page 268 

□ "Preparing Silent Installations and Uninstallations" on page 273 

□ "Using Group Policy Object Distribution" on page 285 

ProxyClient Compatibility with SGOS 

Before you deploy the ProxyClient, make sure the ADN manager, backup 
manager (if any), concentrators and the Client Manager in your ADN network are 
running compatible versions of SGOS. In general, use the following guidelines: 

□ Make sure the ADN manager, ADN backup manager (if any), concentrators, 
and Client Manager are running the most recent version of SGOS. 

□ If you need to upgrade ProxySG appliances, do so in the following order: 

a. ADN Manager and ADN backup manager, if any 

b. Concentrators 

c. Client Manager 



d. ProxyClient software on client computers 

The following table summarizes SGOS compatibility with the ProxyClient 
(version 3.1.x) and the SG Client (version 2.1.x): 





5.3 CM 
5.3 ADN 
Mgr 
5.3 Con 


5.3 CM 
5.3 ADN 
Mgr 
5.2 Con 


5.3 CM 
5.2 ADN 
Mgr 
5.2 Con 


5.2 CM 
5.2 ADN 
Mgr 
5.2 Con 


5.2 CM 

5.3 ADN 
Mgr 
5.2 Con 


5.2 CM 

5.3 ADN 
Mgr 
5.3 Con 


SG Client 
version 2.1.x 


Compatible 


Compatible 


Compatible 


Compatible 


Compatible 


Compatible 


ProxyClient 
version 3.1.x 


Compatible 


Compatible 


Compatible 


Not 

compatible 


Not 

compatible 


Not 

compatible 



In other words, SGOS 5.3 is backward compatible with the SG Client version 2.1.x. 
However, to use the ProxyClient version 3.1.x in your ADN network, your Client 
Manager and ADN Manager (and backup manager, if any) must rim SGOS 
version 5.3.x. In addition. Blue Coat recommends all concentrators that provide 
ADN tunnels for ProxyClients be upgraded to SGOS version 5.3.x. 
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Overview of Distributing the ProxyClient Software 

Administrators can make ProxyClient software available to users in any of the 
following ways: 

□ Interactive installations started from: 

• A command line on the user's machine 

• The Client Manager 

For more information, see "Preparing Interactive Installations" on page 268 

□ Silent installations 

For more information, see "Preparing Silent Installations and Uninstallations" 
on page 273 

□ Windows Group Policy Object distribution 

For more information, see "Using Group Policy Object Distribution" on page 
285 

□ Windows Systems Management Server (SMS) distribution 

For more information about SMS, consult the documentation provided with 
your SMS server. 



Note: For the user to run ProxyClientSetup . exe or ProxyClientSetup .msi, the 

user must be in the Administrators group on the client machine. 



Important: 

• Do not rename ProxyClientSetup. msi; doing so causes future updates to 
fail. 

• Do not edit Proxyciientconf ig . xml after it has been downloaded to the 
client machine; instead, click Check for Updates Now on the ProxyClient Web 
browser window's Advanced tab page to get updates from the Client 
Manager. 
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Preparing Interactive Installations 

Users can install the ProxyClient software either by downloading 
Proxy client Set up . exe from the Client Manager, or manually by running 
ProxyClientSetup.msi from a command line, as shown in the following table: 

Table 12-3 ProxyClient Installation Options 



Option 


Description 


Install from Client 
Manager 


Provide users the URL to ProxyClientSetup.exe, which 
displays on the Client Manager tab page when you select 
ProxyClient > Client Manager. 

ProxyClientSetup.exe downloads and runs 
ProxyClientSetup.msi on the client machine. Users see 
the installation in progress and have the option of 
canceling the installation. 

For more information about this installation method, see 
"Interactive Installations from the Client Manager" on 
page 268. 


Install from the command 
line 


To install the ProxyClient using ProxyClientSetup.msi, 
users must first download it to the client machine, then 
execute it from the command line as discussed in 
"Interactive Manual Installations" on page 272. 

Note: For a complete discussion of 

ProxyClientSetup.msi command-line parameters, see 
"Preparing Silent Installations and Uninstallations" on 
page 273. 



Note: Users who run the ProxyClient setup application must be in the 
Administrators group on the client machine. Also, although it is possible for users 
to run the .msi, it is not recommended because the installation will fail unless the 
user provides parameters on the command-line (for example, bcsi updateurl). 



Interactive Installations from the Client Manager 

To interactively install the ProxyClient software from the Client Manager, the user 
must be in the Administrators group on the client machine. 

To enable users to run ProxyClientSetup.exe from the Client Manager: 

Send users an e-mail with the URL to Proxyciientsetup . exe on the Client 
Manager. 

The URL displays when on the ProxyClient > Client Manager > Client Manager tab 
page. 
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To install the ProxyClient using this method: 

1. Get the URL or location from which you access Proxyciientsetup . exe. 

2. Click the URL in an e-mail or enter it in your browser's address field. 

3. ProxyClientSetup.exe starts the setup application — Proxyciientsetup. msi — 

that installs the ProxyClient software. 

The following dialog displays if you use Internet Explorer 6: 




4. Click Run. The following dialog displays if your browser is Internet Explorer 6: 




Note: The Security Warning dialog displays because Proxyciientsetup . exe is 
not signed. This is because Proxyciientsetup.exe is unique to each Client 
Manager, which in turn makes signing it by a recognized certificate authority 
difficult. 



5. Click Run. 
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The ProxyClient software download begins. During the download, a progress 
dialog similar to the following displays: 




When the download completes, the InstallShield Wizard dialog displays. 




6. Click Next. 

7. The Destination Folder dialog allows you to determine the folder location to 
which ProxyClient is installed. Blue Coat recommends that you install to the 
default directory: c: \Program FiiesXBiue coat\Proxy client. To accept the 
default click Next and proceed to Step 8. 
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To install to a directory of your choosing, click Change. The Change Current 
Destination Folder dialog displays. Click the icons to navigate to a folder and 
click Ok. 




8. When are satisfied with your installation preparation decisions, click Install. 
The Installing Blue Coat ProxyClient wizard dialog displays. 



f'4 Blue Coat ProxyClient - Insta IIS hie Id Wizard fC|fP [ X | 



Installing Blue Coat ProxyClient 

The program features you selected are being installed. 





Please wait while the InstallShield Wizard installs Blue Coat ProxyClient. This 
may take several minutes. 



Status: 






Cancel 
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When the installation is complete, a dialog displays. 




• Click Restart Now to reboot the system immediately 

• Click Restart Later to reboot the system at a later time. Select this option to 
save work before you reboot. 

Interactive Manual Installations 

To enable users to manually install the ProxyClient software: 

Provide a location from which the user can download Proxyciientsetup .msi to 
the client machine; for example, provide the user the URL to the Client Manager. 



Important: Do not rename Proxyciientsetup. msi; doing so causes future 

updates to fail. 

Do not edit ProxyConfig. xml on the client machine; instead, click Check for Updates 
Now on the Advanced tab page in the ProxyClient Web browser window to get 
updates from the Client Manager. 



To install the ProxyClient using this method: 

1. Download Proxyciientsetup .msi to a location on the local file system. 

2. Perform either of the following: 

• Select Start > Run, then enter the command shown in step 3. 

• Open a DOS command prompt window and change to the directory to 
which you downloaded Proxyciientsetup. msi 

3. Enter the following command: 

pa th\ ProxyClient Setup . msi BCS I_UPDATEURL= url -to-config . xml 

where path is the absolute file system path to Proxyciientsetup. msi (if 
necessary), uri-to-config.xmi is the URL to ProxyConfig. xml on the Client 
Manager. 
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This URL displays when you select ProxyClient > Client Manager and click the 
Client Manager tab as discussed in "Designating a ProxySG as the Client 
Manager" on page 210. 

For example, 

ProxyClient Set up .msi BCSI_UPDATEURL=http : / /mysg . example . com: 8084/ 
proxy/ ProxyClientConfig . xml 



Note: Other command-line parameters are available. For a complete list, see 
"Preparing Silent Installations and Uninstallations" on page 273. 



4. The installation proceeds as discussed in steps 1-5 in "Interactive Installations 
from the Client Manager" on page 268. 

Preparing Silent Installations and Uninstallations 

This section discusses how to silently install or uninstall the ProxyClient. 

This section includes the following topics: 

□ "Parameters for Silent Installations" on page 274 

□ "Command for Silent Uninstallations" on page 278 

□ "Example Installations and Uninstallations" on page 279 

Important: Do not rename Proxyciientsetup.msi; doing so causes future 

updates to fail. 

Do not edit ProxyClientConfig . xml on the client computer after it has been 
downloaded from the Client Manager. Instead, click Check for Updates Now on the 
Advanced tab page of the ProxyClient's Web browser window to get a 
configuration update. 



For information about distributing the ProxyClient software using Group Object 
Policy, skip this section and see "Using Group Policy Object Distribution" on page 



285. 
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Parameters for Silent Installations 

The following table shows parameters to use with Proxyciientsetup.msi for silent 
installations. For examples, see "Example Installations and Uninstallations" on 
page 279. 

Silent installation Usage 

ProxyClientSetup.msi [/qf I /qb I /qr | /qn] BCSI_UPDATEURL= url 
REINSTALL=ALL REINSTALLMODE=vamus [ AUTOUPDATEPROHIBI TED=0 I 1 ] 
[FORCEREBOOT={ yes | no } I { y | n } ] [REBOOTTIME= secs] 

[ REGI STRYSETT I NGS= set tings] [NO_UI_SHORTCUT={ 0 | 1 } [/l*v logfile ] 

Silent Installation Parameters 

The following table shows the meanings of the parameters that can be used for 
silent installations; for examples, see "Example Installations and Uninstallations" 
on page 279: 



Table 12-4 Parameters for Silent ProxyClient Installations 



Parameter 


Argument 


Description 


/qf | /qb | /qr | /qn 
I /quiet 




Sets the user interface level (in other words, the extent to 
which the installer interface displays to the user). 

/qf (fully visible and interactive, the default) enables the 
user to see and interact with the installer and to cancel the 
installation. 

/qb (basic) 

/qr (reduced) enables the user to see and interact with the 
installer and to cancel the installation. 

/qn or /quiet (totally silent) prevents the user from 
seeing or interacting with the installer and from canceling 
the installation. 

Note: Because this is an msiexec parameter, other options 
are available. Enter msiexec at a command prompt for 
more information about other options. 


BCSI UPDATEURL 


url 


URL to ProxyClientConf ig . xml on the Client Manager, 
which you can find as discussed in "Designating a 
ProxySG as the Client Manager" on page 210, entered in 
the following format: 

https : // client-manager-host: client-manager- 
port /proxy client /ProxyClientConf ig . xml 


REINSTALL 


ALL 


Installs all ProxyClient components, whether they are 
already installed or not. 

ALL is the only supported parameter value in this release. 
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Table 12-4 Parameters for Silent ProxyClient Installations (Continued) 



Parameter 


Argument 


Description 


REINSTALLMODE 


vamus 


Blue Coat recommends using vamus as the parameter 
value. Because this is an msiexec parameter, other 
options are available. For more information, see the 
description of the reinstallmode parameter on the 
MSDN Web site. 


AUTOUPDATEPROHIBITED 


0 1 1 


0 (default) means the ProxyClient automatically 
implements software updates at the interval the 
administrator specified for software update interval in 
"Designating a ProxySG as the Client Manager" on page 
210. 

1 means only the ProxyClient configuration can be 
updated (automatically or manually), but the ProxyClient 
software cannot be updated. Use this setting if you want 
to distribute software updates in some way other than the 
Client Manager, such as GPO or SMS. 

Note: Regardless of the value of this setting, the client 
always gets configuration updates automatically when 
they are available. Users can also get configuration 
updates manually. 


FORCEREBOOT 


yes | no 
y | n 


yes or y mean the dialog displays with only a Restart Now 
button and a progress bar that increments until the 
computer reboots. (Flowever, if reboottime=0, neither a 
dialog nor progress bar displays.) 

no or n (default) mean a dialog displays with two options: 
Restart Now and Restart Later, enabling users to either 
reboot immediately, wait for the timer to expire (see the 
next parameter), or wait until a later time of their 
choosing. 


REBOOTTIME 


secs 


Number of seconds after the ProxyClient installation 
completes before the user's machine is rebooted. A non- 
zero value means a counter displays on the post- 
installation reboot dialog. 

A value of 0 means there is no timer before rebooting; to 
the user, a value of 0 has different meanings, depending 
on the value of FORCEREBOOT. For more information, see 
"Example Installations and Uninstallations" on page 279. 

The default is 0. 
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Table 12-4 Parameters for Silent ProxyClient Installations (Continued) 



Parameter 


Argument 


Description 


NOUI SHORTCUT 


0 1 1 


Set to 1 to hide the Start menu option for the ProxyClient: 
Start > [All] Programs > Blue Coat ProxyClient > 
ProxyClient. To start the ProxyClient browser window, a 
user must double-click the ProxyClient shortcut located 

in %SystemDrive% : \Program Files\Blue 
Coat \ ProxyClient. 

Set to 0 to show the Start menu option. 

The default is 0. 


REGISTRYSETTINGS 


"name: data- 
type: value" 


Colon-delimited, semicolon-separated list of registry 
settings to create for the client. For more information, see 
Table 12-5. 


/l*v 


logf ile 


If you want the installation to be logged, enter the 
absolute file system path and file name of the log file. 

The user installing the software must have permission to 
write to the indicated folder and the folder must be 
available during the installation; therefore, you should 
avoid specifying a network drive. 



Table 12-5 shows the available arguments for the registrysettings parameter. 
This parameter sets the key name, data type, and value of ProxyClient registry 
settings under HKEY_LOCAL_MACHINE\SOFTWARE\Blue Coat Sys terns \ Proxy Client. 
Examples of using these settings can be found in "Limiting ProxyClient Visibility 
and Interactivity" on page 281. 



Important: Blue Coat strongly recommends testing these registry settings 

before deploying them in a production environment. Improper registry settings 
might cause the installation to fail or to not function as expected. 
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Table 12-5 Parameters for ProxyClient registry settings 



Key name 


Data type 


Value 


CacheDi rectory 


REG SZ 


Set the folder in which ProxyClient byte and CIFS cache 
files are stored. The directory you specify must already 
exist. For example, 

REGI STRYSETTINGS="CacheDi rector y : REG SZ : 
D:\BCCacheDir" 

By default, with no registry key specified, cache files are 
stored in the following folder: 

• Windows XP 

%SystemDrive%\Documents and 
Settings\LocalService\Local 

Settings\Application Data\Blue Coat\Blue Coat 
ProxyClient 

• Windows Vista 

%SystemDrive%\ Windows \ 
system32\config\systemprof ile\ 
AppData\Local\Blue Coat\Blue Coat ProxyClient 


ChangeCMAl lowed 


REG DWORD 


Allowed values: 0 | 1 

Set to l to allow the user to change the Client Manager. 
For example, 

REGISTRYSETTINGS=" ChangeCMAl lowed : REG DWORD: 1" 

Set to 0 to prevent the user from changing the Client 
Manager. 

The default is 0. 


TiNotVisible 


REG DWORD 


Allowed values: 0 | l 

Set to 1 to hide the ProxyClient system tray icon and pop- 
up messages except to indicate that software updates are 
being downloaded, or if the computer must be rebooted 
to apply a software update. For more detail about 
ProxyClient icon states, see "Limiting ProxyClient 
Visibility and Interactivity” on page 281. 

For example, 

REGISTRYSETTINGS="TiNotVisible : REG DWORD: 1" 

Set to 0 to display the ProxyClient tray icon and pop-up 
messages. 

The default is 0. 
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Table 12-5 Parameters for ProxyClient registry settings 



Key name 


Data type 


Value 


T iNotVi sib le Force- 
Update 


REG DWORD 


Allowed values: 0 | l 

Set to l to force ProxyClient software updates on client 
computers without user interaction. This registry setting 
does not depend on the setting for TiNotVisible; in 
other words, setting the value of this key to l means 
clients always get updates regardless of whether or not 
the tray icon is hidden. 

For example, 

REGISTRYSETTINGS="TiNotVisibleForceUpdate: 

REG DWORD : 1 " 

Set to 0 to apply ProxyClient software updates normally; 
that is, provided updates are allowed, users must install 
the updates manually. 

The default value is 0. 

Note: Regardless of the value of this registry key, clients 
always get configuration updates automatically at the 
update interval you set using Configuration > ProxyClient 
> General > Client Manager. Clients can also get 
configuration updates manually at any time. 



Command for Silent Uninstallations 

To silently uninstall the ProxyClient software, use the following command: 

msiexec /X{D35B0C7A-4545-4A98-A810-3810B3FE25E5} /quiet 
The string {d35B0C7a-4545-4A98-a810-3810b3fe25E5} identifies the ProxyClient 
installer's MSI product code. 
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During uninstallation, the ProxyClient removes: 

□ The SG Client (this is the pre-SGOS 5.3 version of ProxyClient). 

□ All ProxyClient drivers, folders, files, the service, and so on. 

□ ProxyClient cache files and the cache folder. 

Note: Users who have administrative privileges on their machines can uninstall 
the ProxyClient using the Control Panel > Add or Remove Programs application. 



Example Installations and Uninstallations 

This section shows the following examples: 

□ "Example Installations" on page 279 

□ "Example Uninstallation" on page 281 

Additional examples are discussed in "Limiting ProxyClient Visibility and 
Interactivity" on page 281. 



Important: Do not rename Proxyciientsetup.msi; doing so causes future 

updates to fail. 

Do not edit Proxyciientconf ig . xml on the client computer after it has been 
downloaded. Instead, click Check for Updates Now on the Advanced tab page of the 
ProxyClient's Web browser window to get updates. 



Example Installations 

Example 1: Automated, interactive installation, manual software updates 
possible, cache directory located in D:\BccacheDir: 

ProxyClientSetup .msi / qr BCSI_UPDATEURL=https : / /mysg . example . com: 8084/ 
proxyclient/ProxyClientConfig . xml REINSTALL=ALL REINSTALLMODE=vamus 
FORCEREBOOT=no REBOOTT IME=3 0 

REG I STRYSETTINGS="CacheDi rectory: REG_SZ : D : \BCCacheDir " 

The ProxyClient configuration downloads from the Client Manager at 
https : / /mysg. example . com: 8 084. The user sees the installation in progress and 
can cancel it. 

The reinstall and reinstallmode parameters cause all ProxyClient 
components to install, which is useful in cases where you are recovering from 
an incomplete or previously unsuccessful installation. 

After the installation is complete, a dialog counts down from 30 seconds to the 
time the computer will reboot automatically. When the dialog displays, the 
user has the following options: 

• Click Restart Later in the dialog to defer rebooting until a later time. 

• Click Restart Now in the dialog to reboot immediately. 
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The registrysettings parameter locates the cache directory in d: \BccacheDir. 
This directory must exist prior to the installation; otherwise, the default cache 
directory will be used. 

Example 2: Automated, interactive installation; the user has the ability to change 
the Client Manager using the ProxyClient browser window 

ProxyClientSetup .msi /qr BCSI_UPDATEURL=https : //mysg . example . com: 8084/ 
proxyclient/ProxyClientConf ig . xml REINSTALL=ALL REINSTALLMODE=vamus 
FORCEREBOOT=yes REBOOT TIME=30 

REGISTRYSETTINGS="ChangeCMAllowed:REG_DWORD: 1" 

The ProxyClient configuration downloads from the Client Manager at 
https : / /mysg. example . com: 8 084. The user sees the installation in progress and 
can cancel it. The reinstall and reinstallmode parameters make sure that all 
ProxyClient components install, which is useful in cases where you are 
recovering from an incomplete or previously unsuccessful installation. 

The registrysettings parameter creates a registry key that enables users to 
change the Client Manager using the ProxyClient browser window (for more 
information, see "Changing the Client Manager" on page 313). 

After the installation is complete, the user has the following options: 

• Wait 30 seconds for the machine to reboot. 

• Click Restart Now in the dialog to reboot immediately. 

Example 4: Automated, interactive installation without a timer 

ProxyClientSetup .msi /qr BCSI_UPDATEURL=https : //mysg . example . com: 8084/ 
proxyclient/ProxyClientConf ig . xml REINSTALL=ALL REINSTALLMODE=vamus 
FORCEREBOOT=no REBOOTTIME=0 

The ProxyClient configuration downloads from the Client Manager at 
https : / /mysg . example . com : 8 08 4 . The user sees the installation in progress and 
can cancel it. The reinstall and reinstallmode parameters make sure that all 
ProxyClient components install, which is useful in cases where you are 
recovering from an incomplete or previously unsuccessful installation. 

After the installation is complete, the user has the following options: 

• Click Restart Later in the dialog to defer rebooting until a later time. 

• Click Restart Now in the dialog to reboot immediately. 

Example 5: Totally silent installation, immediate reboot 

ProxyClientSetup .msi /qn BCSI_UPDATEURL=https : //mysg . example . com: 8084/ 
proxyclient/ProxyClientConf ig . xml REINSTALL=ALL REINSTALLMODE=vamus 
FORCEREBOOT=yes REBOOTTIME=0 

The ProxyClient configuration downloads from the Client Manager specified 
at https : / /mysg. example, com: 808 4. The user does not see the installation in 
progress and cannot cancel it. The user 's machine is rebooted immediately 
after the installation is complete. The reinstall and reinstallmode 
parameters make sure that all ProxyClient components install, which is useful 
in cases where you are recovering from an incomplete or previously 
unsuccessful installation. 
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Example Uninstallation 

msiexec /X{D35B0C7A-4545-4A98-A810-3810B3FE25E5} /quiet 
The string {d35B0C7a-4545-4A98-a810-3810b3fe25E5} identifies the ProxyClient 
installer's MSI product code. 

Limiting ProxyClient Visibility and Interactivity 

This section discusses how to limit ProxyClient application visibility and user 
interaction with the ProxyClient software. You can implement any or all of the 
following options: 



Option 


Setting 


Force ProxyClient software and 
configuration updates on clients without 
user interaction 


TiNotVisibleForceUpdate registry 
key set to l 


Hide the ProxyClient system tray icon 


TiNotVisible registry key set to 1 


Hide the ProxyClient Start menu option 


NOU I SHORTCUT installer switch 



Registry keys and installer switches are discussed in more detail in "Command for 
Silent Uninstallations” on page 278. 

The following table shows the ProxyClient tray icon states and how they are 
affected by these settings: 



Icon 


Icon meaning 


Registry setting 


Description 


& 


Normal 


Default: TiNotVisible 

registry key not present 


Always displays 


Invisible: 

TiNotVisible Set to 1 


Never displays 
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Icon 


Icon meaning 


Registry setting 


Description 


Ql 


Warning state (for 
example, low disk space 
or updates are available) 


Default: 

• TiNotVisible registry 
key not present 

• TiNotVisible- 
ForceUpdate set to 0 


Always displays to warn users 
about critical states or when user 
action is required (for example, to 
get software updates manually) 


Invisible but interactive: 

• TiNotVisible set to 1 

• TiNotVisible- 
ForceUpdate registry 
key not present 


Never displays; configuration 
updates are downloaded 
automatically but the user must 
get software updates manually. 
However, if software updates are 
disabled (AutoUpdate- 
Prohibited registry key set to l), 
the user never gets software 
updates. 


Invisible and non- 
interactive: 

• TiNotVisible set to 1 

• TiNotVisible- 
ForceUpdate set to 1 


Displays only to indicate that 
software updates are currently 
being downloaded; configuration 
updates are downloaded 
automatically but the icon does 
not display. 


g 


Reboot required 


TiNotVisible registry 
key not present, set to 0 or 
set to l 


Displays to indicate that a reboot 
is required after a software update 
or driver failure. 



Note: 

• In the preceding table, only the *31 (critical) icon state depends on both 

TiNotVisible and TiNotVisibleForceUpdate. The other icon states are not 
affected by TiNotVisibleForceUpdate. 

• To enable users to get software updates if you hide the system tray icon or Start 
menu option, set the AutoUpdateProhibited registry key to 0. You can do this by 
editing the registry or by installing the ProxyClient software with the 
AUTOUPDATEDPROHIBITED installer option absent or set to 0. 



To use these options after you install the ProxyClient software, see "Limiting 
ProxyClient Visibility After Installation" on page 315. 

Examples 

This section provides the following examples: 

□ Example of installation allowing partially interactivity: Hiding the system 
tray icon, and requiring clients to accept software updates without interaction: 

ProxyClientSetup .msi / qn BCSI_UPDATEURL=https : / /mysg . example . com: 8084/ 
proxyclient/ProxyClientConfig . xml REINSTALL=ALL REINSTALLMODE=vamus 
FORCEREBOOT=yes REGISTRYSETT I NGS=" TiNotVisible : REG_DWORD : 1 ; 
TiNotVisibleForceUpdate : REG_DWORD : 1 " 
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This example sets the following options: 



Option 


Description 


/qn 


Performs a non-interactive installation. 


BCSI UPDATEURL=https : //mysg . example . com: 8084 / 
proxyclient/ProxyClientConf ig . xml 


Specifies the URL from which clients obtain 
policy. 


REINSTALL=ALL 


Installs all ProxyClient components, 
whether they are already installed or not. 


REINSTALLMODE=vamus 


For more information, see the description 
of the REINSTALLMODE parameter on the 
MSDN Web site. 


FORCEREBOOT=ye S 


Forces clients to reboot after installing the 
ProxyClient software. 


REGISTRYSETTINGS="TiNotVisible : REG DWORD : 1 ; 
TiNotVisibleForceUpdate : REG DWORD : 1 " 


• TiNotVisible:REG DWORD :1 

Hides the ProxyClient system tray icon 
unless software updates are being 
downloaded. The icon also displays after 
the updates have been installed to 
indicate the computer must be rebooted. 

• TiNotVisibleForceUpdate : REG DWORD: 

l 




Requires clients to accept software 
updates when they are available. User 
interaction is not permitted. 

However, if the AutoUpdateProhibited 

registry key is set to 1 , it takes 
precedence and software updates are 
never downloaded. 



□ Example of installation with no application visibility or interactivity: 

Installing the ProxyClient to hide the system tray icon, hide the Start menu 
option, and require clients to accept upgrades without interaction: 



ProxyClientSetup .msi / qn BCSI_UPDATEURL=https : / /mysg . example . com: 8084/ 
proxyclient/ProxyClientConf ig . xml REINSTALL=ALL REINSTALLMODE=vamus 
FORCEREBOOT=yes NO_UI_SHORTCUT=l 
REGISTRYSETTINGS="TiNotVisible : RE G_ DWORD : =1 ; 

TiNotVisibleForceUpdate : REG_DWORD : 1 " 
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This example sets the following options: 



Option 


Description 


/qn 


Performs a non-interactive installation. 


BCSI UPDATEURL=https : / /mysg . example . com: 8084 / 
proxyclient/ProxyClientConf ig . xml 


Specifies the URL from which clients obtain 
policy. 


REINSTALL=ALL 


Installs all ProxyClient components, 
whether they are already installed or not. 


REINSTALLMODE=vamus 


For more information, see the description 
of the REINSTALLMODE parameter on the 
MSDN Web site. 


FORCEREBOOT=ye S 


Forces clients to reboot after installing the 
ProxyClient software. 


NO UI SHORTCUT=l 


Hides the ProxyClient Start menu option. 
To view the ProxyClient browser window, 
the user must double-click the 
ProxyClient shortcut located in 

%SystemDrive% : \Program Files\Blue 
Coat \ ProxyClient 


REGISTRYSETTINGS="TiNotVisible : REG DWORD : =1 ; 
TiNotVisibleForceUpdate : REG DWORD : 1 " 


• TiNotVisible:REG DWORD :1 

Hides the ProxyClient system tray icon 
unless software updates are being 
downloaded. The icon also displays after 
the updates have been installed to 
indicate the computer must be rebooted. 

• TiNotVisibleForceUpdate : REG DWORD: 
1 

Requires clients to accept software or 
configuration updates when they are 
available. User interaction is not 
permitted. 

However, if the AutoUpdateProhibited 

registry key is set to 1 , it takes 
precedence and software updates are 
never downloaded. 
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Using Group Policy Object Distribution 

This section discusses how to distribute the ProxyClient software using Windows 
Group Policy Object (GPO). 

Important: Only an experienced Windows administrator should attempt to 

complete the tasks discussed in this section. 

To distribute the ProxyClient software using GPO: 

1. Get an .msi transform tool, such as the Orca database editor. 

Orca is a table-editing tool available in the Windows Installer SDK that can be 
used to edit your .msi files. You can also use similar tools available from other 
vendors. 



Note: Blue Coat does not recommend a particular transform tool. 

For more information about Orca, see Microsoft KB article 255905. 

The remainder of this section assumes you use Orca. Consult the 
documentation provided with the transform tool you are using for vendor- 
specific instructions. 

2. Open ProxyClientSetup . msi. 

3. Perform the following changes to the Property table: 



Note: Be advised, this action invalidates the signature on the MSI. 



Table 12-6 ProxyClient setup property table changes 



Property 


Action 


Value 


BCSI UPDATEURL 


Add 

row 


Required for all installations. 

URL to ProxyClientConf ig . xml on the Client 
Manager, entered in the following format: 

https:/ / client-manager-host:client- 
manager-port/ proxyclient/ 
ProxyClientConf ig . xml 


FORCEREBOOT 


Edit 

value 


Required for all installations. 

Change the value from n to y. This value causes 
the user 's machine to reboot after the 
ProxyClient is downloaded, which is required to 
use the ProxyClient. 
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Table 12-6 ProxyClient setup property table changes 



Property 


Action 


Value 


REINSTALL 


Add 

row 


Add this row and set it to all only if you want to 
update the ProxyClient software and 
configuration using GPO. 

If clients get future ProxyClient software and 
configuration updates from the Client Manager, 
do not add this row. 


REINSTALLMODE 


Add 

row 


Add this row and change it to vamus only if you 
want to update the ProxyClient software and 
configuration using GPO. 

If clients will get future ProxyClient software 
and configuration updates from the Client 
Manager, do not add this row. 


AUTOUPDATEPROHIBITED 


Edit 

value 


Change the value from 0 to 1 only if you want to 
update the ProxyClient software in some way 
other than from the Client Manager, such as 
using GPO or SMS. (Configuration updates are 
obtained from the Client Manager whose URL is 
specified by the bcsi updateurl parameter 
discussed earlier in this table.) 






1 means only the ProxyClient configuration can 
be updated (automatically or manually), but the 
ProxyClient software cannot be updated. Use this 
setting if you want to distribute software 
updates in some way other than the Client 
Manager, such as using GPO or SMS. 

If clients will get future ProxyClient software 
updates from the Client Manager, leave this 
value at 0. 
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4. To implement registry changes discussed in Table 12-5 on page 277, use the 
following steps: 

a. Add one row to the Registry table for every registry setting you wish 
to set. 

b. In the Add Row dialog box, enter the following information: 



Field 


Description 


Registry 


Enter a unique description of the registry entry. The 
value you enter is not written to the registry; it is used 
only to identify the entry. The value must begin with 

Registry. 

For example, Registryl. 


Root 


Enter 2. 


Key 


Enter the ProxyClient registry path relative to 

hkey local machine, Software\Blue Coat 
Systems\Proxy Client 


Name 


Enter the name of the registry key; see Table 12-5 on 
page 277. 


Value 


Enter the value of the registry key. 

Note: If the value is REG_DWORD, you must preface 
the value with the number sign (#). For example, a 
registry key value of l must be entered as #1 . 


Component 


Enter ProxyClientSvc.exe. 



5. Generate the transformation. 
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Section E: About the ProxyClient Application 

This section provides an overview of the ProxyClient application that runs on 
user systems. Review this section so that you are aware of your users interaction 
with ProxyClient. 

The user interface allows users to view statistics and Web filtering verdicts, 
manually retrieve configuration and policy updates from the Client Manager, 
perform basic troubleshooting tasks, and forward diagnostic information to 
system administrators. 



Note: The descriptions in this section are brief; for more detailed explanations of 
specific options, access the Help file in the application. 



How Users Access the ProxyClient Application 

Users access the application by: 

□ Selecting from the Windows Start menu: [All] Programs > Blue Coat ProxyClient > 
ProxyClient. 

□ Double-clicking the ProxyClient shield icon in the system program tray. 

□ Right-clicking the ProxyClient shield icon in the system program tray and 
selecting Show Status. 



Note: To prevent users from seeing the ProxyClient application or knowing it is 
running, you can optionally hide the tray icon as discussed in "Limiting 
ProxyClient Visibility and Interactivity" on page 281. 



ProxyClient starts in a Web browser window. If your default Web browser is 
Internet Explorer, the ProxyClient starts in an Internet Explorer window. If your 
default Web browser is Firefox, the ProxyClient starts in a Firefox window. 

If your default Web browser is neither Internet Explorer nor Firefox, the 
ProxyClient starts in an Internet Explorer window. 
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About the Status Tab Page 

The first page users see is the Status tab page. 



BlueOCoat ProxyClient 
Status 

Acceleration Statistics 



Running Q | Location: HomeVPN | Help 0 



Status: Running Q 




Total URL Requests: 


117 




Allowed: 


116 




Warned: 


1 




Denied: 


0 



Most Recent Ewents 
O Warned 

http://icep2.ebay.com/ad/212041 
(firefox.exe) Reason: Category 
(Auctions) 




Reset Statistics 



More Loos 



Figure 12-6 The ProxyClient Status tab page 

The Status tab page contains the following components: 



□ A: Client Status: The status of the application (running or disabled for various 
reasons) and the network location detected by the ProxyClient. 

□ B: Acceleration Status and Statistics: If acceleration is enabled, this area displays 
in the application, providing statistics indicating the bandwidth use gain 
provided by ProxyClient. Users can view total savings or savings over the 
previous specified time period. The Status link is an active link; users can 
disable acceleration. 



□ C: Web Filtering Status and Statistics: If Web filtering is enabled, this area displays 
and provides to users Web filtering verdicts (Warned and Denied verdicts). The 
Status link is not an active link; users cannot disable Web filtering. 



Note: The More Logs link displays a dialog that provides an expanded list of 

events, such as filtering verdicts and various ProxyClient network and module 
connections. 
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About the Network Tab Page 

The Network tab page provides ADN and network connectivity information. 



BlueQCoat ProxyClient 
Network 



Running © I Help Q 



Configuration 

Primary ADN Manager: 10.9.59.210 

Backup ADN Manager: N/A 

Included Ports: 80, 139, 445, 8080 

Excluded Subnets: N/A 



ADN Tunnels 








Current Active Tunnels: 




1 


Current Idle Tunnels: 




1 


Current Direct Connections: 




0 




Mge Info 



Subnets 


Exempt Routes 


<3 


Address 


Net Mask 


ADN Next Hop 


Address 


Net Mask 


ADN Next Hop 


10.150.0.0 


255.255.255.0 


10.9.59.210 


10.0.0.0 


255.0.0.0 


10.9.59.210 








172.16.0.0 


255.240.0.0 


10.9.59.210 








192.168.0.0 


255.255.0.0 


10.9.59.210 



Figure 12-7 The ProxyClient Network tab page 

The Network tab contains the following components: 



□ A: Configuration: This information reflects the Client Manager configuration. 

• The IP addresses of the Primary and Backup ADN Managers (Configuration > 
ProxyClient > Acceleration > ADN Manager tab). 

• The Ports list might be Included or Excluded. If it is Included Ports, the 

ProxyClient listens for traffic only on the listed ports; conversely, if 
Excluded Ports displays, the ProxyClient listens on every port except those 
listed. 



□ B: ADN Tunnels: Am ADN tunnel is a network connection that increases 
performance over a Wide Area Network (WAN). 

The More Info link displays a dialog with granular data relating to the 
bandwidth gain and savings provided by the ProxyClient. 

□ C: Subnets: Displays the next ADN hop ; that is, the IP address of a concentrator 
on a different subnet that is advertising routes and accelerating traffic for the 
ProxyClient. 

□ D: Exempt Routes: These are network routes that your administer identified as 
internal to the enterprise, thus do not require processing by the ProxyClient. 
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About the Advanced Tab Page 

The Advanced tab page provides ProxyClient update information and basic 
diagnostic tools. 



BlueOCoat ProxyClient 



Status I Network 



Advanced 



Running © I Help © 



■^Software Version 


Software Version: 


3. 1.0.4 


▼ Less... 




Filename 


Version 


ProxyClientSvc.exe 


3. 1.0. 4 (34088) 


ProxyClientUI.exe 


3. 1.0. 4 (34088) 


ProxyClientDC.exe 


3. 1.0. 4 (34088) 


ProxyClient.dll 


3. 1.0. 4 (34088) 


Proxy ClientFlt. sys 


3. 1.0. 4 (34088) 


ProxyClientWebFilter. sys 


3. 1.0. 4 (34088) 



B 


Software Update 






Auto Update: 


On © 

Check For Uodates 



■ Client Manager 




Client Manager Address: 


10.9.59.210 


Last Log Upload: 


N/A 


Last Configuration Change: 


6 hours ago 


Last Successful Update Check: 1 hour 

ago 




D 



E 



The Advanced tab contains the following components: 



□ A: Software Version: The current version of ProxyClient software. Clicking More 
displays the individual component version and software build (and changes 
the option to Less). 

□ B: Software Update: This area allows users to manually check for software and 
configuration (such as Web filtering policy) updates. Clicking the link 
displays a small dialog that informs the user if any updates occurred. If you 
have elected to not enable automatic updates, the Auto Updates status is off 
and users must periodically perform a manual check. 

□ C: Client Manager: This area displays the Client Manager address, the last time 
the access logs were uploaded, and how long the last update check and 
configuration change occurred. 
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□ D: Diagnostic Tools: These options allow users to (when instructed) perform 
ProxyClient process traces. These traces can be for all processes or limited to 
acceleration or Web filtering processes. For more detailed troubleshooting 
information, see "Performing Data Traces and Data Collection" on page 317. 
Also, users can click View Log to see a list of recent actions. For details, see 
"Admin Log Contents" on page 292. 

□ E: Disk Cache: Allows users to clear the ADN object cache. See "Client Manager 
Logging" on page 305. 

Admin Log Contents 

The ProxyClient software maintains a diagnostic log that records the following: 

• Client installation (the timestamp of the initial installation and any 
updates, including errors). 

• Activation of the driver and client service components every time those 
components start. 

• Configuration download events (whenever a configuration download is 
attempted and whether it succeeded or failed). 

• Connection information between the client machine and the ADN 
manager. 

• ADN tunnel creation and destruction. 

• Activation/ deactivation of the trace log, which is discussed in more detail 
in "Performing Data Traces and Data Collection" on page 317. 

• Various error conditions (for example, out of memory, out of disk space, 
and so on). 

Log entries include the date and time of each event. The log file is a maximum of 

20MB in size, after which the oldest log entries are deleted as new entries are 

written. 
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Section F: Monitoring ProxyClient Performance 

This section discusses the following topics: 
a "Viewing History Statistics" 

Statistics > ProxyClient History 

Aggregated bandwidth usage statistics related to the ProxyClient and all 
concentrators in the network, and with the Client Manager (for example, 
number of clients, number of software updates, and number of configuration 
updates). 

□ "Viewing ProxyClient ADN History Statistics" on page 295 

Statistics > ADN History 

Statistics related to the ProxyClient and a particular concentrator. To view 
statics related to ProxyClients and all concentrators on the network, view the 
BW Usage tab page on Statistics > ProxyClient History. 

□ "Viewing ProxyClient Active Session Statistics" on page 296 

Statistics > Sessions > Active Sessions > ADN Inbound Connections 

Statistics related to inbound ADN connections to a concentrator from 
ProxyClients. 

Viewing History Statistics 

This section describes how to view the following statistics: 

□ Client Manager: Current active ProxyClients, the number of software updates, 
number of configuration updates, and ProxyClient version information. 

□ Concentrators: Bandwidth usage aggregated for all concentrators. 

To view ProxyClient history statistics: 

1. Log in to a ProxySG appliance's Management Console as an administrator. 
The statistics you view depend on the role of the appliance, as follows: 

• Client Manager: To view Active Clients, Configurations Served, Software 
Served, or Client Version Count. 

• Concentrator: To view BW Usage. 

2. From the Management Console, select Statistics > ProxyClient History. 
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3. Click a tab to view statistics. The ProxySG displays graphs for each tab (except 
the Client Version Count tab) in different selectable time increments, varying 
from the last hour to the last year. Hover the mouse pointer over any graph on 
the page to see metric data. 

• Bandwidth Usage: Aggregated statistics for all ProxyClients using this Client 
Manager. 

• C: The number of bytes sent and received by the applications running 
on the client's computer (that is, corresponding to the Total Demand 
graph in the ProxyClient browser window). 

• S: The number of bytes sent over the WAN after acceleration was 
applied (that is, corresponding to the Actual Usage graph in the 
ProxyClient browser window). 

• Gain: The magnitude of bandwidth gain. 

• Savings: The percentage of bandwidth savings. 

• Active Clients: Track how many ProxyClients are active on the network. 
Any ProxyClient that does not report for ten consecutive minutes is 
treated as inactive. 

• Configurations Served: Track how many times the ProxyClient configuration 
file was downloaded from the Client Manager. 

• Software Served: Track how many times updated ProxyClient software was 
downloaded to user systems. 
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• Client Version Count: View the total number of active ProxyClients by 
software version number. 

Viewing ProxyClient ADN History Statistics 

These statistics relate to bandwidth usage and gain from ProxyClient connections 
to a specific concentrator. To view aggregated statistics for bandwidth usage and 
gain for all concentrators in the network, see "Viewing History Statistics" on page 
293. 

To view ProxyClient ADN History statistics: 

1. Log in to a concentrator's Management Console as an administrator. 

2. Click Statistics > ADN History. 




3. From the Duration list, click a time frame. 

4. View the following statistics: 

The displayed statistics represent all ADN traffic processed by this 
concentrator. ProxyClients are aggregated into one peer group, with 
ProxyClients as the Peer ID and Peer IP. 

Other appliances on the network devices are listed by IP address. 

The other attributes for both usage and gain are: 

• Optimized Bytes: How many bytes were sent using the ADN tunnel. 

• Unoptimized Bytes: How many bytes would have been sent over the 
network had ADN not been used. 

By comparing optimized bytes and unoptimized bytes, you can determine 
how much savings was realized by using ADN. 

• Savings: The performance gained by ADN processing. 
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Viewing ProxyClient Active Session Statistics 

Active session statistics display current bandwidth usage and savings 
information between ProxyClients and a particular concentrator. 

To view Active Session statistics: 

1. Log in to a concentrator's Management Console as an administrator. 

2. Click Statistics > Sessions > Active Sessions > ADN Inbound Connections. 



Click Show 



Defined below- 



Proxied Sessions 
j None 



Filter: 



Bypassed Connections 

3 * 



ADN Inbound Connections 



Show 



V Display the most recent [" 



connections 



r ADN Inbound Connections - 





Client 


Server 


Peer 


|Dura.. 


| Unopt. ... | Opt. Bytes] 


Savings 


F 


BC 


E | Tunnel Type 


♦ 


10.107.0.187 


66.150.208.54:80 


10.107.0.... 


1 sec 


2,320 


1,112 




88 


0101 

O 


2 Client 


♦ 


10.107.0.187 


4.71.104.187:80 


10.107.0.... 


1 sec 


2,389 


1,380 


Q 


88 


0101 

O 


2 Client 


• 


10.107.0.187 


74.203.241.34:80 


10.107.0.... 


1 sec 


33,267 


33,428 


0% 


88 


0101 

O 


Q Client 


♦ 


10.107.0.187 


64.236.29.63:80 


10.107.0.... 


2 sec 


4,603 


2,448 




88 


0101 

O 


3 Client 


♦ 


10.107.0.187 


64.236.91.21:80 


10.107.0.... 


2 sec 


4,486 


2,055 




88 


0101 

O 


2 Client 



Terminate Connection 



Download 



3. At the top of the ADN Inbound Connections tab page, click Show to display 
statistics from active sessions. 



• Client — The IP address of the ProxyClient (for example, the outbound IP 
address of the VPN application). 

• Server — The IP address of the final destination server (such as a content 
server). 

• Peer — For ProxyClients, client and peer IP addresses are the same because 
ProxyClient mimics a branch ProxySG. 

• Duration — How long the active session has been connected. 

• Unopt. Bytes — The number of bytes served to or from the server before or 
after ADN optimization. For example, the number of bytes sent to a server 
before the traffic was optimized by ADN. 

• Opt. Bytes — The number of bytes optimized by ADN processing. 

• Savings — The performance gained by ADN processing. 

• C — Whether the data is compressed or not. 

86 (compressed) displays if the data is being compressed. 

(not compressed) if compression is not being used. 

• BC — Whether or not byte caching was used. 
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• E — Whether or not the incoming ADN tunnel is encrypted. In this release, 
ProxyClient connections are not encrypted. 

• Tunnel — The type of TCP tunnel; ProxyClient connections are always 
identified as Client. 



297 



Volume 5: Advanced Netzvorking 



Section G: About the ProxyClient System Footprint 

Section G: About the ProxyClient System Footprint 

This section lists each file and folder on user systems impacted by the installation 
and removal of the ProxyClient application. This chapter divides the information 
into the following sections: 

□ "Installation" on page 298 

• "Folders" on page 298 

• "Files" on page 299 

• "Setup Executable" on page 299 

• "Setup MSI" on page 299 

• "Installed Files" on page 300 

• "Shortcuts" on page 300 

• "Registry" on page 301 

• "During Runtime" on page 302 

□ "During Runtime" on page 302 

• "Logging and Support" on page 302 

• "Acceleration Files" on page 302 

• "Web Filter Files" on page 303 

• "Data Collector" on page 303 

□ "Removal" on page 303 

Installation 

This section lists all of the folders and files affected by installation. 

Folders 

Installation affects the following folders. 



Table 12-7 Folders affected by installation 



Name Used in the 
Document 


Default Path 


Notes 


Temp 


%temp% 


This is the user's 
temporary folder. 


Support 


%SystemDrive%\Documents and 
Settings\All Users\Application 
Data\Blue Coat 
Sys terns \ProxyClient\ support 


Diagnostic data is stored 
here. 


Installation Target 


%SystemDrive%\Program Files\Blue 
Coat\ ProxyClient 


Default installation 
location. 
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Table 12-7 Folders affected by installation 



Name Used in the 
Document 


Default Path 


Notes 


Drivers 


%SystemDrive%\WINDOWS\ system32\ 
drivers 


None 



Files 

Installation affects the following files. 
Table 12-8 Files affected by installation 



File Name 


Location 


ProxyClientSetup . exe 


If the file is opened directly from the 
browser, it will be downloaded to the 
Internet Explorer's temporary Internet 
files folder. 


ProxyClientSetup .msi 


%TEMP% 


InstallSupport . log 


Support folder 


proxyclient log . etl 


Support folder 


ProxyClientSetup exe . log 


Support folder 


ProxyClientSetup msi . log 


Support folder 



Setup Executable 

The user can download the setup executable to any location on the system (disk). 
The executable is a single file that downloads the setup MSI to the Temp folder 
before execution (see "Setup MSI" for details about the MSI package). 
Additionally, it creates the support folder. Within this folder the executable creates 
the install support log, the setup log for the executable, and a trace ( . eti) file. 
After it downloads the MSI, the executable runs the MSI to perform the actual 
installation. 

Setup MSI 

This is to be run either by the setup executable or directly by the user (or by a 
software distribution mechanism, such as SMS or GPO). If the Support folder and 
files have not already been created by the setup executable, the MSI creates the 
folder and files. The MSI package itself is approximately 7 MB in size. 
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Installed Files 

The MSI installs the majority of the ProxyClient files to the Installation Target, 
with the exception of the drivers, which are installed in the Drivers folder. The 
following table lists these files. 

Table 12-9 List of installed files. 



File Name 


Description 


ProxyClient 


Shortcut for the ProxyClient application 


ProxyClientSvc . exe 


ProxyClient service executable 


ProxyClientUI . exe 


ProxyClient tray icon executable 


ProxyClient . dll 


ProxyClient acceleration /web filtering 
library 


ProxyClientDC . exe 


ProxyClient Data Collector utility 


SGClientEula . html 


End User License Agreement 


Chartdir . dll 


User interface support library 


SGCustomAction . dll 


Installation support library 


Bridge . pyc 


User interface support file 


StringTable . pyc 


User interface support file 


ProxyClientConf ig . xml 


ProxyClient configuration and policy 
file (downloaded from Client Manager) 


ProxyClientFlt . sys 


Acceleration driver (written to Drivers 
folder) 


ProxyClientWebFilter . sys 


Web Filter driver (written to Drivers 
folder) 



Additionally, several user interface files are written to the include and webroot 
folders under the Installation Target. The total size of the installed files (not 
including the initial configuration file) is approximately 10 MB. The size of the 
configuration file varies in size, from 2 KB to several MB. 

Shortcuts 

The MSI also creates a shortcut in the Start menu. The shortcut is called ProxyClient, 
and is in the Blue Coat ProxyClient folder. No shortcuts are created on the desktop. 
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Registry 

Table 12-10 lists some of the registry keys used by the ProxyClient. In the table, 
the following abbreviations are used: 

□ hkcr means hkey_classes_root 

□ hkcu means hkey_current_user 

□ hklm means hkey local machine 



Table 1 2—1 OList of registry keys. 



Path 


Purpose 


HKCR\AppID\ {5CDD0A2B-2C5C-4313-83EF- 
A3F4A4551 918} 


Key: Contains data required 
by the service 


HKCU\Software\Blue Coat SystemsXProxy 
ClientX { DE43B3A2-ABC3-E2AE-37EC- 
4C3557CB104E} 


Key: Required by installer 


HKLM\Software\Blue Coat SystemsXProxy Client 


Key: Software settings for 
ProxyClient 

Keys under this node are 
discussed in Table 12-11 on 
page 311. 


HKLM\ So ftware\Microsoft\ Windows \ 
CurrentVersionXRun 


Value: Start tray icon on log- 
in 


HKLMX So ftware\Microsoft\ Windows 
NT\CurrentVer si on XTracingX ProxyClient 
Service 


Key: Diagnostic settings 


HKLMX System\CurrentControlSet\Services\ 
(proxyclientf It , proxyclientwebf ilter , 
WebFilter ) 


Sub-keys (in parentheses) 
created for acceleration and 
web filter drivers 


HKLMX SystemXCurrentControlSetX Control X 
SafeBootXNetworkX proxy client svc 


Key: Start ProxyClient when 
booting in Safe Mode 
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During Runtime 

As the ProxyClient runs, it creates additional files depending on what 
functionality is enabled. When the service runs, an encrypted folder is created 
under the Windows user folder for the Locaiservice account. This provides a 
more secure environment for storing sensitive data. 

Logging and Support 

In the Support folder, if tracing is enabled a file named proxyciientdebug.eti is 
created. Additionally, if the service crashes for any reason, a memory dump file is 
generated in the Support folder. 



Note: Trace files and memory dumps must be sent to Blue Coat Support for 
interpretation. 



If at any point a downgrade is performed through the auto-update mechanism, an 
additional downgrade log is created in the Support folder. 

Acceleration Files 

When acceleration is enabled, this encrypted folder contains the byte and object 
cache files in a protected environment. The size of the cache varies by machine, 
and is determined by the amount of free space on the drive as well as the 
configured amount of disk space to use. 

The cache directory is used for both byte caching and CIFS caching, with each 
cache using approximately have of the available space. The size of the files in the 
cache directory are limited; 1GB free space is always available on the client 
computer. For more information, see "More About ProxyClient Caching" on page 
224. 

The default location of the cache directory follows: 

□ Windows XP 

%SystemDrive%\Documents and Settings\LocalService\Local 
Settings\Application Data\Blue Coat\Blue Coat ProxyClient 

□ Windows Vista 

%SystemDr ive%\Windows\ 

system32\config\systemprof ile\AppData\Local\Blue Coat\Blue Coat 
ProxyClient 

To change the location of the cache directory, see one of the following sections: 

□ To set the cache directory when you install the ProxyClient software, see 
"Command for Silent Uninstallations" on page 278. 

□ To change the location of the cache directory after the software is installed, see 
"Changing the Location of the Cache" on page 324. 
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Web Filter Files 

When Web filtering is enabled, activity is logged to the encrypted folder. The log 
files are periodically uploaded, and the extent of the data to be logged is 
determined by the administrator. 

Data Collector 

The Data Collector utility, which is installed with the ProxyClient, creates a folder 
within the Temp folder as a repository for the collected data. The contents of the 
Support folder are copied here, and several new files are created. The specifics of 
the folder's contents are discussed in other documents about the Data Collector. 



Note: The Data Collector is a troubleshooting utility. For more details, see 
"Instructing Users to Run the ProxyClient Data Collector" on page 319 



Removal 

When the ProxyClient is removed from a user's system, all installed software and 
drivers are removed, including: 

□ The object cache 

□ The Web filter cache 

□ Support data 

□ Registry data 

□ Application shortcut 

Contents Left Behind 

No files that were created in the Temp folder are removed. There is currently no 
mechanism to track all of the files that are created there. However, these files are 
safe for removal at any time. 

Immediately following the removal of the ProxyClient (but before rebooting), it 
might appear that some files created by the software or the installation process 
have not yet been removed. This is because the files are still in use by other system 
resources. 

When this happens, the removal process marks the files for removal upon reboot. 
Windows automatically removes them the next time that the system is restarted. 
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Section H: ProxyClient Troubleshooting 

For administrators to assist ProxyClient users with diagnosing errors, you must 
be familiar with the topics discussed in this section: 

□ "About HTTPS Browser Proxies" on page 304 

□ "Client Manager Logging" on page 305 

□ "Acceleration Troubleshooting" on page 306 

□ "Web Filtering Troubleshooting" on page 307 

□ "Advanced Troubleshooting" on page 310 

□ "Performing Data Traces and Data Collection" on page 317 

□ "Clearing the Cache" on page 323 

□ "Changing the Location of the Cache" on page 324 

□ "Uninstalling the ProxyClient Software" on page 325 

Note: If ProxyClient users are unable to get software or configuration updates 
from the Client Manager or if network acceleration is not working, make sure 
your firewall has the following ports open: 

• Client Manager listen port (by default, 8084) 

• ADN manager's plain listen port (by default, 3034) 

• Concentrator's plain tunnel port (by default, 3035) 



About HTTPS Browser Proxies 

This section discusses how to configure an Internet Explorer browser proxy to 
enable users to download the ProxyClient software and updates. If you do not use 
a proxy for SSL traffic, you can skip this section. 



Note: Because the ProxyClient uses the Internet Explorer proxy settings to 
download software and configuration updates, change the proxy settings in 
Internet Explorer. 



The following options are available: 

□ If users can connect directly to the Client Manager, change the browser's 
proxy settings to exclude the Client Manager from being proxied. 

□ Change the proxy settings to allow connections to the Client Manager listen 
port (by default, 8084). You defined the Client Manager listen port as 
discussed in "Designating a ProxySG as the Client Manager" on page 210. 
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Client Manager Logging 

The Client Manager logs success or failure events related to users downloading 
the ProxyClient software and configuration. Each log should include timestamp, 
HTTP GET string (including the HTTP return code), and client machine name. 

To obtain Client Manager logs: 

Enter the following URL in your browser's address field: 

https : / /host: port/ proxyclient/log 

where host is the fully qualified host name or IP address of the Client 
Manager, and port is the ProxySG appliance's listen port. 

Client Connection Issues 

Use standard networking tools such as ping, tracert, telnet, and Internet Explorer 
to understand why the client cannot connect. Because the Client Manager 
protocol is HTTPS and the client uses the standard Windows Wininet library 
(which is also used by Internet Explorer, and shares settings such as proxy 
settings with Internet Explorer), you can use Internet Explorer as the main tool to 
test these types of connectivity problems. 

Verify the user can connect to the Client Manager from Internet Explorer by 
entering the URL of the Client Manager. For example: 

https : // client_manager_IP_address: 8084/ 



Note: For remote users, a VPN connection might be required to access the Client 
Manager. 



If Internet Explorer can access this URL, the client should also be able to 
communicate with the Client Manager. If this is not the case, look for: 

□ Things that might block traffic on the desktop for specific applications, such as 
desktop security products. 

□ Application-specific settings on the remote access VPN solution (verify that 
traffic from the Proxyciientsvc . exe service is handled by the VPN solution). 



Note: If ProxyClient users are unable to get software or configuration updates 
from the Client Manager or if network acceleration is not working, make sure 
your firewall has the following ports open: 

• Client Manager listen port (by default, 8084) 

• ADN manager's plain listen port (by default, 3034) 

• Concentrator's plain tunnel port (by default, 3035) 
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Acceleration Troubleshooting 

The main sources of information for troubleshooting are the ProxyClient, the 
Client Manager (for checking configuration and viewing client status), and the 
relevant ProxySG concentrator. If you suspect there are ADN routing problems, 
you can use the ADN manager for troubleshooting. 



Note: If ProxyClient users are unable to get software or configuration updates 
from the Client Manager or if network acceleration is not working, make sure 
your firewall has the following ports open: 

• Client Manager listen port (by default, 8084) 

• ADN manager's plain listen port (by default, 3034) 

• Concentrator's plain tunnel port (by default, 3035) 



About ADN Tunnels 

On the Network tab page of the ProxyClient browser window, clicking the More Info 
link in the ADN Tunnels area displays detailed information about available tunnels, 
including whether a tunnel is idle or bypassed. 

An idle tunnel is one that is not currently being used but preserves connection 
connection information to decrease the amount of time required to use that 
connection later, if necessary. 

A direct tunnel indicates an error with the connection to the indicated ProxySG. 

Diagnosing the Concentrator 

This section provides what to look for on the concentrator: 

□ Statistics > Active Sessions > ADN Inbound Sessions displays information about 
currently active sessions, including sessions with ProxyClients. Use a client IP 
address filter to view tunnels from a specific client. 

For more information, see "Viewing ProxyClient Active Session Statistics" on 
page 296 

To view related client statistics, see the discussion of the Live ADN Session 
View in "Diagnosing the ProxyClient" on page 307 

□ Statistics > Advanced > ADN: 

• The Peer statistics link displays aggregate information per peer (client). For 
each peer, it shows byte cache information such as dictionary status and 
cache size. 

• The tunnel connection link shows information per each active connection. 

• The tunnel connection pool link shows information about idle tunnels. 
This correspond to the idle tunnels displayed on the client side Live ADN 
Session View. 



306 



Chapter 12: Accelerating and Controlling Micro-Branch and Mobile User Connections (ProxyClient) 



Section H: ProxyClient Troubleshooting 

• The dashboard link and other links display aggregate information for 
components such as tunnels and dictionary sizes. 

Diagnosing the ProxyClient 

This section provides what to look for on the client side of the ADN. Most of the 

information provided by ProxyClient is statistical, but it might help you narrow 

the ADN device causing the issues. 

□ The Admin log (Advanced tab > Diagnostic Tools area) displays any error 
conditions with established connections to the ADN Manager and to the 
Concentrators. The log also displays successful events for connecting to the 
ADN manager and establishing a new tunnel to a concentrator. However, it 
does not show successful accelerated connection events. 

□ Advanced Acceleration Admin Log — When this is activated, successful 
accelerated connection events will also be recorded in the Admin Log. 

□ The ProxyClient tray icon displays warnings or errors (such as pending 
configuration updates and updates that require rebooting). Hover the mouse 
pointer over the icon to display details. 

□ ProxyClient user interface: 

• The Acceleration Statistics area of the Status tab provides information about 
total traffic gains (totals and historic charts). 

• The Network tab provides information about the current ADN 
configuration. For example, which subnets and ports are accelerated 
(Configuration, Subnets, and Exempt Routes areas). The ADN Tunnels area 
displays the number of active tunnels, idle tunnels, and direct 
connections. The ADN managers are listed in the Configuration area. 

• The More Info link in the Network tab > ADN Tunnels area displays a dialog 
referred to as the Live ADN Session View. This dialog displays all 
currently accelerated connections, idle tunnels, and direct connections, 
each with statistics showing acceleration gains (if accelerated), activity, 
and the process that owns the connection. 

• The user can disable acceleration by clicking on the Status link on the Status 
tab > Acceleration Statistics area. 

Web Filtering Troubleshooting 

The following sections provide methods to diagnose Web filtering issues reported 

by users: 

a "Why Are Users Receiving Blocked or Warn Messages For No Justifiable 
Reason?" 

□ "ProxyClient Web Filtering Licensing" on page 309 

□ "Disputing URL Categorization For ProxyClient" on page 309 
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Why Are Users Receiving Blocked or Warn Messages For No 
Justifiable Reason? 

The most common message you are likely to receive from your users is that 
ProxyClient is denying them access to a Web site that they feel does not violate 
Web-use policy 

The first step is to understand why the page is blocked or warned: 

□ The rating server returned a category that resulted in a block action. The 
exception page, admin log, and Most Recent Events list displays the category 
that caused the block action. 

□ The rating server did not return a category, and the none system category is 
configured with a block action. 

□ None the BCWF service points (rating servers) are available, and the 
unavailable system category is associated with a block action. 

□ License expiration is fail closed and the Client Manager is not licensed for 
ProxyClient Web Filtering or does not have a fresh BCWF database. 
ProxyClient displays Not licensed as the Web Filtering status on the Status tab. 
The tray icon mouse over text also displays this state. 

□ The service is not running or not responding, and the unavailable system 
category is configured with a policy action of block. In this case, the tray icon 

displays as Q (needs reboot). The ProxyClient browser interface and admin 
log are not available in this case. 

□ After uninstalling the ProxyClient software but before rebooting because the 
ProxyClient blocks all URLs when a reboot is required. 

□ After a software update has been received but before the computer is rebooted 
if the unavailable system category is configured with a block action. 

In other words, software updates require a reboot. Between the time the 
update is installed and the time the user reboots, the policy action for the 
unavailable system category is applied. 

□ by the client because the client blocks all URLs when a reboot is required. 
Software updates always require a reboot. 

Normal Web filtering resumes after the user reboots. 

□ Some images on requested pages do not display. This is most likely caused by 
subsequent requests on an allowed Web page falling into a blocked category. 
(For example, a section or portlet on an allowed Web page might contact a 
prohibited site for an advertisement.) 

Advise your users this is expected behavior. 

More detailed information for most of these events can be retrieved by activating 
the Advanced Web Filtering Admin Log (see "Instructing Users to Perform Data 
Traces" on page 318). 
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Various actions to remedy unjustified block (and warn) actions are available, 
depending on the reason for the block action: 

□ Add a URL to a custom category that is associated with an allow action (that 
is, create a whitelist). Move this category above the category that is causing 
the block action. This causes the allow action to be processed first. 

You also have the option to disagree with the rating decision made by BCWF 
and submit a request for categorization change. 

See "Disputing URL Categorization For ProxyClient" on page 309. 

□ Consider modifying the rule base, allowing the blocked category, allowing 
none or unavailable categories, or changing the unlicensed behavior to fail open. 
This option is valid if you are authorized to change the corporate compliant 
browsing policy. 

□ Fix the license violation. See "ProxyClient Web Filtering Licensing" on page 
309. 

□ Restart ProxyClient to fix non-responsive services. 

ProxyClient Web Filtering Licensing 

If your users notify you that the application displays the Filtering Unlicensed 
message, the BCWF license is no longer valid or the URL database has not been 
refreshed in the last 30 days. 

On the Configuration > Content Filtering > Blue Coat > Blue Coat Web Filter tab page, 
verify you have a valid license and click Download now to update the database. 

Disputing URL Categorization For ProxyClient 

In the event users report they are blocked from accessing a normally allowable 
Web site, first make sure the problem is not caused by improper ordering of 
categories in the Web filter rulebase. This is particularly true if a single URL is 
listed in multiple categories. 

For more information, see "Web Filtering Best Practices" on page 251. 

If BCWF is blocking access to the Web site and you disagree with the URL's 
categorization. Blue Coat enables you to submit a Web site for review, stating 
ProxyClient as the Web filter source. 
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To dispute a ProxyClient Web filter rating: 

1. In your Web browser's address or location field, enter: 

http: //sitereview.bluecoat . com/ site review. j sp 

The Web Page Review Process page displays. 

2. In the field, enter the URL to be reviewed and click Submit. 

3. On the second Web Page Review Process page, select Blue Coat ProxyClient from 
the Filtering Service drop-down list. 

4. From the first What category or categories does this site belong to? drop-down list, 
select the category you believe the site belongs to. You can optionally select a 
secondary category (for example, if your Web filtering policy allows one 
category, but not the other). 

5. (Optional) Select Please send results of the Site Review via email if you want Blue 
Coat to notify you of the submission verdict. 

6. In the Comments and Site Description field, enter a detailed message to Blue Coat 
site reviewers explaining your reason for this submission. 

7. Click Submit. 

Advanced Troubleshooting 

This section discusses advanced troubleshooting tools and procedures for 
administrators. The tasks discussed in this section should be performed only by 
administrators, or by users with assistance from administrators. 

Following is a brief discussion of each troubleshooting tool: 



Task 


Description 


Detail 


For more 
information 


Change the 
Client Manager 
URL 


Enables you to connect to a Client 
Manager other than the one from which 
you initially downloaded the 
ProxyClient software. The typical use is 
running ProxySG demonstrations, trials, 
and evaluations from different ADN 
networks. 


After you set the 
required registry key, 
click the Advanced tab. 
In the Client Manager 
section, the Client 
Manager Address 
value is a link. 


"Changing the 
Client 

Manager" on 
page 313 


Support trace 


Collects ProxyClient process information 
(that is, both acceleration or Web 
filtering) and provides more details than 
the Admin Log. 


Advanced tab page, in 
the Diagnostic Tools 
section. 


"Instructing 
Users to 
Perform Data 
Traces" on page 
318 


Advanced logs 


Enables users to collect detailed trace 
information for acceleration or Web 
filtering individually, or for both. 


Advanced tab page, in 
the Diagnostic Tools 
section. Click More 
under Admin Log. 


"Performing 
Data Traces 
and Data 
Collection" on 
page 317 
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Task 


Description 


Detail 


For more 
information 


Data collector 


Collects diagnostic information useful to 
troubleshoot unexpected behavior and 
connectivity problems. 


Enables users to collect 
logs and system 
information so you can 
analyze the problem 
and refer it to Blue 
Coat Support, if 
necessary. If you have 
an SR number, you can 
attach data collector 
output to the SR ticket. 


"Instructing 
Users to Run 
the ProxyClient 
Data Collector” 
on page 319 


Registry 

settings 


See Table 12-11. 



Table 12-11 summarizes ProxyClient registry settings: 



Table 12-11 ProxyClient registry settings 



Key name 


Data type 


Value 


AutoUpdateProhibited 


DWORD 


0 (default) means the ProxyClient automatically 
implements software updates at the interval the 
administrator specified for software update interval 
in "Designating a ProxySG as the Client Manager" on 
page 210. 

1 means only the ProxyClient configuration can be 
updated (automatically or manually), but the 
ProxyClient software cannot be updated. Use this 
setting if you want to distribute software updates in 
some way other than the Client Manager, such as 
GPO or SMS. 

Note: Regardless of the value of this setting, the client 
always gets configuration updates automatically 
when they are available. Users can also get 
configuration updates manually. 
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Table 12-11 ProxyClient registry settings 



Key name 


Data type 


Value 


CacheDirectory 


STRING 


Set the folder in which ProxyClient cache files are 
stored. The path must already exist; otherwise, the 
default cache directory is used. 

The default cache directory follows: 

• Windows XP 

%SystemDrive% : \Documents and 
Settings\LocalService\ Local 
Settings\Application Data\Blue Coat\Blue 
Coat ProxyClient 

• Windows Vista 

%SystemDrive% : \Windows\ 
system32\conf ig\systemprof ile\ 
AppData\Local\Blue Coat\Blue Coat 
ProxyClient 

For more information, see "Changing the Location of 
the Cache" on page 324. 


ChangeCMAl lowed 


DWORD 


Allowed values: 0 | 1 

Set to l to allow the user to change the Client 
Manager. 

Set to 0 to prevent the user from changing the Client 
Manager. 

The default is 0. 

For more information, see "Changing the Client 
Manager” on page 313. 


TiNotVisible 


DWORD 


Allowed values: 0 | 1 

Set to 1 to hide the ProxyClient system tray icon and 
pop-up messages except in certain circumstances. 

Set to 0 to display the ProxyClient tray icon and pop- 
up messages. 

By default, this registry key does not exist. 

For more information, see "Limiting ProxyClient 
Visibility After Installation" on page 315. 
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Table 12-11 ProxyClient registry settings 



Key name 


Data type 


Value 


TiNotVisibleForceUpdate 


DWORD 


Allowed values: 0 | 1 

Set to l to force users to accept software and 
configuration updates without interaction. This key is 
independent of TiNotVisible; in other words, the 
setting for this key determines update behavior 
whether or not the ProxyClient tray icon is hidden. 

Set to 0 to allow updates normally; that is, users 
always get configuration updates. Software updates 
can be installed manually. 

By default, this registry key does not exist. 

Note: The availability of software updates is 
controlled by the AutoUpdateProhibited registry 
key. If AutoUpdateProhibited is set to 1, users 
cannot get software updates, regardless of the value 
of this registry key. For more information, see 
"Parameters for Silent Installations" on page 274. 

For more information, see "Limiting ProxyClient 
Visibility After Installation" on page 315. 



Changing the Client Manager 

You can change which Client Manager the ProxyClient uses if, for example, you 
want to run trials or demonstrations on a different ADN network than the one for 
which you initially configured the ProxyClient. 



Note: After you change the Client Manager IP address, the client gets a 
configuration update immediately The behavior of software updates is not 
changed; in other words, if you prohibited software updates, the client will not 
attempt get a software update after it connects to the new Client Manager. If 
software updates are allowed, the client gets an update at the next update 
interval. 



To change the Client Manager URL: 

1. Set the changeCMAi lowed registry key in any of the following ways: 

• When the ProxyClient software is installed as discussed in Table 12-5 on 
page 277. 

• After installing the ProxyClient software as discussed in the next step. 

2. If a user is not allowed to change the Client Manager URL and the ProxyClient 
is already installed, perform the following tasks: 

a. Start a registry editor application like regedit. 
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b. Browse to the following node: 

HKEY_LOCAL_MACHINE\SOFTWARE\Blue Coat SystemsXProxyClient 

c. Double-click the ChangeCMAIIowed registry key. 

d. In the Edit DWORD Value dialog, in the Value data field, enter 1. 

e. Click OK. 



Note: It is safe to set this while the service is already running. 



3. In the ProxyClient Web browser window, click the Advanced tab. 

4. In the Client Manager section, click the current Client Manager address link. 
The Change Client Manager dialog displays. 

5. In the Change Client Manager dialog, enter or edit the following information: 



Field 


Description 


New Address 


Enter the Client Manager's fully qualified host name 
or IP address. 


New Port 


Enter the Client Manager's listen port. 



6. Click OK. 

A success or fail message displays in the Change ProxyClient Manager 
browser window as the URL is verified. 

The client gets a configuration update from the new Client Manager 
immediately. If software updates are ready to download at the next update 
interface, and if the client is allowed to get software updates, you are notified 
before the updates are installed. 

When the operation is complete, the Advanced tab page displays the new 
Client Manager host name or IP address. 
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Limiting ProxyClient Visibility After Installation 

This section discusses how to limit ProxyClient application visibility and user 
interaction with the ProxyClient software. You can implement any or all of the 
following options: 



Option 


Setting 


Force ProxyClient software and 
configuration updates on clients without 
user interaction 


TiNotVisibleForceUpdate registry 
key set to l 


Hide the ProxyClient system tray icon 


TiNotVisible registry key set to 1 


Hide the ProxyClient Start menu option 


NOU I SHORTCUT installer switch 



This section discusses how to limit visibility and interaction after the ProxyClient 
software is installed. 

The following table shows the ProxyClient tray icon states and how they are 
affected by these settings: 



Icon 


Icon meaning 


Registry setting 


Description 




Normal 


Default: TiNotVisible 

registry key not present 


Always displays 


Invisible: 

TiNotVisible set to 1 


Never displays 


31 


Warning state (for 
example, low disk space 
or updates are available) 


Default: 

• TiNotVisible registry 
key not present 

• TiNotVisible- 
ForceUpdate set to 0 


Always displays to warn users 
about critical states or when user 
action is required (for example, to 
get software updates manually) 


Invisible but interactive: 

• TiNotVisible set to 1 

• TiNotVisible- 
ForceUpdate registry 
key not present 


Never displays; configuration 
updates are downloaded 
automatically but the user must 
get software updates manually. 
However, if software updates are 
disabled (AutoUpdate- 
Prohibited registry key set to l), 
the user never gets software 
updates. 


Invisible and non- 
interactive: 

• TiNotVisible set to 1 

• TiNotVisible- 
ForceUpdate set to 1 


Displays only to indicate that 
software updates are currently 
being downloaded; configuration 
updates are downloaded 
automatically but the icon does 
not display. 
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Icon 


Icon meaning 


Registry setting 


Description 




Reboot required 


TiNotVisible registry 
key not present, set to 0 or 
set to l 


Displays to indicate that a reboot 
is required after a software update 
or driver failure. 



Note: 

• In the preceding table, only the 53 ) (critical) icon state depends on both 

TiNotVisible and TiNotVisibleForceUpdate. The other icon states are not 
affected by TiNotVisibleForceUpdate. 

• To enable users to get software updates if you hide the system tray icon or Start 
menu option, set the AutoUpdateProhibited registry key to 0. You can do this by 
editing the registry or by installing the ProxyClient software with the 
AUTOUPDATEDPROHIBITED installer option absent or set to 0. 



To install the ProxyClient software with limited visibility and user interaction, see 
"Limiting ProxyClient Visibility and Interactivity" on page 281. 

To limit ProxyClient visibility and interaction after installation: 

1. Log in to a computer running the ProxyClient as an administrator. 

2. Start a registry editor application like regedit. 

3. Navigate to the following node: 

HKE Y_LOCAL_MAC H I NE \ SOFTWARE \ B 1 u e Coat Systems\ProxyClient 

4. Do any of the following: 



To get this behavior 


Perform these tasks 


Hide the system tray icon 


1 . Right-click the ProxyClient key. 

2. From the pop-up menu, click New > DWORD Value. 

3. For the name of the value, enter TiNotVisible. 

4. Double-click TiNotVisible. 

The Edit DWORD Value dialog displays. 

5. In the Value Data field, enter 1 . 

6. Click OK. 


Force users to accept 
configuration and software 
updates without interaction 


1. Right-click the ProxyClient key. 

2. From the pop-up menu, click New > DWORD Value. 

3. For the name of the value, enter 

TiNotVisibleForceUpdate. 

4. Double-click TiNotVisible. 

The Edit DWORD Value dialog displays. 

5. In the Value Data field, enter 1 . 

6. Click OK. 



5. Close the registry editor application. 
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6. Reboot the computer for the changes to take effect. 

The tray icon and pop-up messages are not visible except to notify the user 
that a software update is being downloaded, and to notify the user to reboot 
the computer after updates have been installed. If you prohibit automatic 
software updates, the icon never displays. 

Performing Data Traces and Data Collection 

Traces, logs, and data collection allows users to send you files containing 
ProxyClient process data that you or Blue Coat Support can use to diagnose 
issues. 

This section discusses the following topics: 
a "About ProxyClient Logs" 

□ "About the Data Collection Application" on page 318 

□ "Instructing Users to Perform Data Traces" on page 318 

□ "Instructing Users to Run the ProxyClient Data Collector" on page 319 

About ProxyClient Logs 

Logs are written to the following folder: 

□ Windows XP: 

%SystemDrive%\Documents and Settings\All Users\Application Data\Blue 
Coat Systems\ProxyClient\support 

□ Windows Vista: 

%SystemDrive%\ProgramData\Blue Coat Systems\proxyclient\support 

The ProxyClient creates the following log files: 



Log file name 


Used by 


proxyclientautoupdate . log 


Logs automatic software updates but not 
configuration updates. 


proxyclient log . etl 


Admin log (the log users can view on the 
ProxyClient Web browser window's Advanced tab 
page). 

The admin log contains information about 
acceleration, Web filtering, software upgrades, and 
configuration updates. 

The admin log is written during the entire time the 
ProxyClient is running. 
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Log file name 


Used by 


proxyclientdebug . eti 


• All advanced admin logs on the Advanced tab 
page 

Trace logs contain more information than the 
admin log. Users can enable trace logging for 
acceleration, Web filtering, or both. All trace logs 
are written to this file. 

• Support trace, which records all client activity in 
detail. 



Note: . eti is a binary format that is readable only by Blue Coat Support. 



About the Data Collection Application 

The Proxy client dc application gathers system information to send to Blue Coat 
Support for troubleshooting and debugging purposes. Users have the option of 
collecting logs and e-mailing them to you or sending them directly to Blue Coat 
support and attaching them to an existing Service Request (SR). 

For more information, see "Instructing Users to Run the ProxyClient Data 
Collector" on page 319. 



Instructing Users to Perform Data Traces 

To create trace logs to get assistance from Blue Coat support, ask users to enable 
any of the following: 

□ The support trace, which records all client activity. 

□ Detailed trace activity for acceleration, Web filtering, or both. 

For users to start a trace: 

1. The user starts the ProxyClient Web browser window. 

If you limited the ProxyClient's visibility, see "Limiting ProxyClient Visibility 
After Installation" on page 315. 

2. Click the Advanced tab. 

3. On the Advanced tab page, in the Diagnostic Tools section, click More under 
Admin Log. 

4. Click the Start Trace link next to the trace you wish to start. 

5. Repeat the activity that caused the problem. 

6. Click the Stop Trace link. 

7. Click Open Trace Folder. 

8. Send the appropriate . eti file to Blue Coat Support with detailed information 
about what caused the issue. 
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Note: These instructions are included in the ProxyClient on-line help that is 
available to users. Users can click Help either on the ProxyClient system tray 
icon or in the Web browser window. 



Instructing Users to Run the ProxyClient Data Collector 

Installed in the ProxyClient folder on user systems, the ProxyClient Data 
Collector is a utility that end users run to collect comprehensive system 
information that administrators or Blue Coat Support can use to diagnose 
problems with the ProxyClient application and network connectivity. 

When users access the Data Collector, they must select one of two data collection 
modes: 

□ System Administrator Mode: This mode collects the following information, 
which is intended for corporate network administrators: 

• All ProxyClient logs, including installation logs and diagnostic trace 
messages. 

• A memory dump of the ProxyClient service process. 

• The current configuration file and registry settings. 

• A list of all running processes on the system. 

• Various network-related information (IP configuration, trace route, netstat 
data, and so on). 

□ Blue Coat Mode: If your issue was assigned a Service Response (SR) number, 
the user must enter the SR number to enter Blue Coat mode. In Blue Coat 
mode, the ProxyClient collects the following information in addition to the 
information discussed in the preceding point: 

• Diagnostic trace messages. 

• A full memory dump of the ProxyClient service process. 

To run the ProxyClient Data Collector utility: 

1. The user starts Windows Explorer or double-clicks My Computer. 

2. Locate the ProxyClient installation folder. 

The default location is %SystemDrive%:\Program Files\Blue Coat\Proxy 
ClientV 
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jlE C:\Program Files\Blue Coat\ProxyClient 

X 

3 El Blue Coat 

ProxyClient 
(±1 £) include 
(S £) webroot 
□ O Blue Coat Reporter 
Q Extras 

B Q LogAnalysisInfo 
a Q Databases 
IS E) docs 
(S Q graph_colors 
a Q IPC 
a Ei language 



(^include 

0 webroot 
[sl] bridge .pyc 
l*) chartdir.dll 

ProxyClient . dll 

1 = , ProxyClientConfig 

""1 ProxyClientSvc^ 
C| ProxyClientUI 
^SGClientEula 
,V) 5GCustomAction.dll 
[sj]StrinqTable.pyc 



Double-click 



3. Double-click the ProxyciientDC application. 



The Blue Coat ProxyClient Data Collector dialog displays. 




4. Choose the mode in which to run the Data Collector. 
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Options are discussed in the following table. 



Option 



'V Blue Coat ProxyClient Data Collector 



Please consult your system administrator about which oP the below options to choose. Note 
that sensitive data may be collected when choosing to send data to Blue Coat. 



Action 




Ask users to select this 
option if you suspect a 
configuration or 
network problem. 



0 Gather general diagnostic data for the System Administrator 
O Gather detailed diagnostic data for the Blue Coat Support team 



Next > 




If you have entered a 
support case with 
Blue Coat Support and 
have received an SR 
number, provide users 
with that number. The 
user should select the 
check box and enter 
the SR number in the 
provided field. 



> 1 ' Blue Coat ProxyClient Data Collector 



Please consult your system administrator about which oP the below options to choose. Note 
that sensitive data may be collected when choosing to send data to Blue Coat. 



m 



O Gather general diagnostic data for the System Administrator 
0' Gather detailed diagnostic data for the Blue Coat Support team 
[d Automatically upload data directly to Blue Coat SR # 



Next > 



Alternate: If you do 
not have an SR 
number but want to 
collect detailed 
information for Blue 
Coat Support, clear 
the check box. After 
the data collection 
process completes, ask 
the user to send you 
the file so you can 
contact Blue Coat 
Support. 



5. Click Next. 



The Data Collector starts and displays the Blue Coat ProxyClient 
DataCollector dialog. 
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Figure 12-8 Green check marks indicate successful task completion. 

Note: The preceding example shows collecting data in System Administrator 
mode. If the user selects Blue Coat Support mode, additional tasks are 
performed. 



A green check mark displays next to each task as it completes successfully 
(some tasks might require several minutes to complete). At any time, click 
Stop to stop the data collection process (for example, the process appears hung 
on one stage). 

6. After ProxyClient completes all of the tasks: 

• System Administrator Mode or Blue Coat mode without selecting the 
check box to send the data to Blue Coat. Instruct users to: 



a 


Click View collected data. The collected files display in Windows 
Explorer. 


b 


Right-click the . zip file (begins with proxyciientdc- and ends with 
the user's system name and date/ timestamp) and select Send to > 
My Documents. 


c 


E-mail the . z ip file to you. 


d 


Click Exit. 
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• Blue Coat Mode (with the Automatically upload data directly to Blue Coat 

option selected): ProxyClient automatically forwards the information and 
associated case number to Blue Coat Support. Click Exit. 

• Blue Coat Mode — connection error: If users experience a connection 
error — that is, ProxyClient cannot upload to Blue Coat — instruct them to 
run the Data Collector in Blue Coat Mode again, but do not select 

Automatically upload data directly to Blue Coat. 

Clearing the Cache 

Clearing the object cache might be necessary to free disk space if disk space 
becomes critical. Because the object cache improves network performance, you 
should consider this action only after the user removes other unnecessary 
applications and files. 

Clearing the object cache removes files for both byte caching and CIFS 
optimization. These files are located by default in one of the following hidden 
folders: 

□ Windows XP 

%SystemDrive%\Documents and Settings\LocalService\Local 
Settings\Application Data\Blue Coat\Blue Coat ProxyClient 

□ Windows Vista 

%SystemDrive%\ Windows \ 

system32\config\systemprof ile\AppData\Local\Blue Coat\Blue Coat 
ProxyClient 

To clear the object cache: 

1. The user double-clicks the ProxyClient system tray icon to start the Web 
browser window. 

If you chose to hide the system tray icon, see "Limiting ProxyClient Visibility 
and Interactivity" on page 281. 

2. Click the Advanced tab. 

3. On the Advanced tab page, in the Disk Cache section, click Clear Cache. 

You are required to confirm the action. 



Note: 

• Clearing the cache while the client is running does not delete files that are 
currently in use. 

• These instructions are included in the ProxyClient on-line help that is 
available to users. Users can click Help either on the ProxyClient system 
tray icon or in the Web browser window. 
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Changing the Location of the Cache 

This section discusses how to change the location the ProxyClient stores CIFS 
cache and byte cache files. 

By default, the cache is stored in the following folder: 

□ Windows XP 

%SystemDrive%\Documents and Settings\LocalService\Local 
SettingsXApplication DataXBlue CoatXBlue Coat ProxyClient 

□ Windows Vista 

%Sys temDrive%\ Windows Xsystem3 2 Xconf igXsystempr of ile\AppData\Local\Blue 
CoatXBlue Coat ProxyClient 

To optionally locate the files on a different volume (for example, a volume that 
has more available space): 

1. If the ProxyClient is already installed, perform the following tasks first: 

a. Double-click the ProxyClient icon in the system tray. 

b. In the ProxyClient Web browser window, click the Advanced tab. 

c. On the Advanced tab page, click Clear Cache. 

You are required to confirm the action. This deletes or expires all the files 
in the cache directory. 

2. Create a registry value named cacheDirectory of type reg sz (that is, string) 
in the following key: 

HKEY_LOCAL_MACHINE\SOFTWARE\Blue Coat SystemsXProxyClient 

3. Set the Value data of CacheDirectory to the location to store the object cache. 



Note: 

• The directory must already exist; otherwise, the default cache directory 
will be used. 

• You can also create the registry key during a silent installation as 
discussed in Table 12-5 on page 277. 



4. Reboot the client computer for the registry key to take effect. 
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Uninstalling the ProxyClient Software 

This section describes how to uninstall the ProxyClient application software from 
user systems. You can uninstall ProxyClient from your system only if you are in the 
Administrators group on the computer. 

For information about silent uninstallation, see "Example Uninstallation" on page 
281. 

To uninstall the ProxyClient software: 

1. Log in to your machine as a user who is a member of the Administrators 
group. 

2. Click Start > Control Panel. 

3. In the Control Panel window, double-click Add or Remove Programs. 

4. Click Blue Coat ProxyClient. 

5. Click Remove. 

6. Follow the prompts to uninstall the software. 

Secondary Procedure 

If you discover the preceding procedure did not remove all traces of the 
ProxyClient software, perform the tasks discussed in this section. 

To uninstall the ProxyClient in Windows Safe Mode: 

1. Boot into Safe Mode without Networking, which means that no ProxyClient 
components are loaded by the system. 

2. Log in as an administrator 

3. Click Start > Settings > Control Panel. 

4. In the Control Panel window, double-click Add or Remove Programs. 

5. Click Blue Coat ProxyClient. 

6. Click Remove. 

7. Follow the prompts to uninstall the software. 
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This chapter discusses the Blue Coat implementation of SOCKS, which 
includes the following: 

□ A SOCKS proxy server that supports both SOCKSv4/ 4a and SOCKSv5, 
running on the ProxySG appliance. 

□ Support for forwarding through SOCKS gateways. 

To configure a SOCKS proxy server on the ProxySG, refer to Volume 2: Proxies 
and Proxy Services. To use SOCKS gateways when forwarding traffic, continue 
with this chapter. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ Section A: "Configuring a SOCKS Gateway" on page 328. 

□ Section B: "Using SOCKS Gateways Directives with Installable Lists" on 
page 337. 
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Section A: Configuring a SOCKS Gateway 

SOCKS servers provide application level firewall protection for an enterprise. 

SOCKS gateways, like ICP and forwarding, can use installable lists for 
configuration. You can configure the installable list using directives. You can also 
use the Management Console or the CLI to create a SOCKS gateways 
configuration. Using the Management Console is the easiest method. 

To configure a SOCKS gateway: 

1. Select Configuration > Forwarding > SOCKS Gateways > SOCKS Gateways. 

2. Click New to create a new SOCKS gateway. 

SOCKS Gateways | SOCKS Gateway Groups | Global Defaults | Default Sequence | Install SOCKS Gateway File 

SOCKS Gateways 

Name Host Port SOCKS Version 




3. Configure the SOCKS gateway as follows: 

a. Alias: Give the gateway a meaningful name. 



328 




Chapter 13: SOCKS Gateway Configuration 



Section A: Configuring a SOCKS Gateway 



Note: SOCKS gateway aliases cannot be CPL keywords, such as no, 

default, forward, or socks^gateways . 



b. Host: Add the IP address or the host name of the gateway where traffic 
is directed. The host name must DNS resolve. 

c. Port: The default is 1080. 

d. SOCKS version: Select the version that the SOCKS gateway can support 
from the drop-down list. Version 5 is recommended. 

e. Username (Optional, and only if you use version 5) The username of the 
user on the SOCKS gateway. The username already must exist on the 
gateway. If you have a username, you must also set the password. 

f. Set Password: The plaintext password or encrypted password of the 
user on the SOCKS gateway. The password must match the gateway's 
information. The password can be up to 64 bytes long. Passwords that 
include spaces must be within quotes. 

You can enter an encrypted password (up to 64 bytes long) either through 
the CLI or through installable list directives. 

g. In the Load Balancing and Host Affinity section, select the load balancing 
method from the drop-down list. Global default (configured on the 
Configuration > Forwarding > Global Defaults tab), sets the default for all 
SOCKS gateways on the system. You can also specify the load 
balancing method for this system: Least Connections or Round Robin, or 
you can disable load balancing by selecting None. 

h. In the Host affinity methods drop-down list, select the method you want 
to use: 

• HTTP: The default is to use the Global Defaults. Other choices are None, 
which disables host affinity. Accelerator Cookie, which places a cookie in 
the response to the client, and Client IP Address, which uses the client 
IP address to determine which upstream SOCKS gateway was last 
used. 

By default, SOCKS treats all incoming requests destined to port 80 as 
HTTP, allowing the usual HTTP policy to be performed on them, 
including ICAP scanning. If the SOCKS connection is being made to a 
server on another port, write policy on the ProxySG to match on the 
server host and port and specify that it is HTTP using SOCKS. 

• SSL: The default is to use the Global Defaults. Other choices are None, 
which disables host affinity. Accelerator Cookie, which places a cookie in 
the response to the client, and Client IP Address, which uses the client IP 
address to determine which group member was last used. In addition, 
you can select SSL Session ID, used in place of a cookie or IP address, 
which extracts the SSL session ID name from the connection 
information. 
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• Other. Other applies to any traffic that is not HTTP, terminated HTTPS, 
or intercepted HTTPS. You can attempt load balancing of any of the 
supported traffic types in forwarding and this host affinity setting can 
be applied as well. For example, you could load balance a set of TCP 
tunnels and apply the Other host affinity (client IP only). 

The default is to use Global Defaults. Other choices are None, which 
disables host affinity, and Client IP Address, which uses the client IP 
address to determine which group member was last used. 

i. Click OK to close the dialog. 

4. Click Apply. 

To create groups: 

Am existing gateway can belong to none, one, or more groups as desired (it can 

only belong once to a single group, however). 

1. Select Configuration > Forwarding > SOCKS Gateways > SOCKS Gateway Groups. 

2. Click New. The Add SOCKS Gateway Group dialog displays. 
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3. To create an alias group, highlight the hosts and groups you want grouped, 
and click Add. 

4. Give the new group a meaningful name. 

5. In the Load Balancing and Host Affinity section, select the load balancing method 
from the drop-down list. Global default (configured on the Configuration > 
Forwarding > SOCKS Gateways > Global Defaults tab), sets the default for all 
forwarding hosts on the system. You can also specify the load balancing 
method for this system: Least Connections, Round Robin, Domain Hash, URL Hash, 
or you can disable load balancing by selecting None. 

6. In the Host affinity methods drop-down lists, select the method you want to use. 
Refer to the previous procedure for details on methods.You are selecting 
between the resolved IP addresses of all of the hosts in the group, not the 
resolved IP addresses of an individual host. 

• HTTP: The default is to use the Global Defaults. Other choices are None, which 
disables host affinity. Accelerator Cookie, which places a cookie in the 
response to the client, and Client IP Address, which uses the client IP 
address to determine which group member was last used. 
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• SSL: The default is to use the Global Defaults. Other choices are None, which 
disables host affinity. Accelerator Cookie, which places a cookie in the 
response to the client, and Client IP Address, which uses the client IP 
address to determine which group member was last used. In addition, you 
can select SSL Session ID, used in place of a cookie or IP address, which 
extracts the SSL session ID name from the connection information. 

• Other. Applies to any traffic that is not HTTP, terminated HTTPS, or 
intercepted HTTPS. You can attempt load balancing of any of the 
supported traffic types in forwarding and this host affinity setting can be 
applied as well. For example, you could load balance a set of TCP tunnels 
and apply the Other host affinity (client IP only). 

The default is to use Global Defaults. Other choices are None, which disables 
host affinity, and Client IP Address, which uses the client IP address to 
determine which group member was last used. 

7. Click OK to close the dialog. 

8. Click Apply. 

Configuring Global SOCKS Defaults 

The global defaults apply to all SOCKS gateways hosts and groups unless the 

settings are specifically overwritten during host or group configuration. 

To configure global defaults: 

1. Select Configuration > Forwarding > SOCKS Gateways > Global Defaults. 




2. Determine how you want connections to behave if the health checks fail: 
Connect Directly (fail open) or Deny the request (fail closed). Note that failing open is 
an insecure option. The default is to fail closed. This option can be overridden 
by policy, if it exists. 

3. In the Global Load Balancing and Host Affinity area: 
a. Configure Load Balancing methods: 
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• SOCKS hosts: Specify the load balancing method for all forwarding 
hosts unless their configuration specifically overwrites the global 
settings. You can choose Least Connections or Round Robin, or you can 
disable load balancing by selecting None. Round Robin is specified by 
default. 

• SOCKS groups: Specify the load balancing method for all forwarding 
groups unless their configuration specifically overwrites the global 
settings. You can choose to hash the domain or the full URL. You can 
also choose Least Connections, Round Robin, Domain Hash, URL Hash, and 
you can disable load balancing by selecting None. Round Robin is 
specified by default. 

b. Configure Global Host Affinity methods: 

• HTTP: The default is to use None, which disables host affinity. Other 
choices are Accelerator Cookie, which places a cookie in the response to 
the client, and Client IP Address, which uses the client IP address to 
determine which group member was last used. 

• SSL: The default is to use None, which disables host affinity. Other 
choices are Accelerator Cookie, which places a cookie in the response to 
the client, and Client IP Address, which uses the client IP address to 
determine which group member was last used, and SSL Session ID, 
used in place of a cookie or IP address, which extracts the SSL session 
ID name from the connection information. 

• Other: Other applies to any traffic that is not HTTP, terminated HTTPS, 
or intercepted HTTPS. You can attempt load balancing of any of the 
supported traffic types in forwarding and this host affinity setting can 
be applied as well. For example, you could load balance a set of TCP 
tunnels and apply the Other host affinity (client IP only). 

The default is to use None, which disables host affinity. You can also 
choose Client IP Address, which uses the client IP address to determine 
which group member was last used. 

c. Host Affinity Timeout: This is the amount of time a user's IP address, SSL 
ID, or cookie remains valid. The default is 30 minutes, meaning that 
the IP address, SSL ID or cookie must be used once every 30 minutes to 
restart the timeout period. 

4. Click Apply. 

Configuring the Default Sequence 

The default sequence defines what SOCKS gateways to use when no policy is 
present to specify something different. The system uses the first host or group in 
the sequence that is healthy, just as it does when a sequence is specified through 
policy. Only one default sequence is allowed. All members must be pre-existing 
hosts, and no member can be in the group more than once. 
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A default failover sequence allow healthy hosts to take over for an unhealthy host 
(one that is failing its DNS Resolution or its health check). The sequence specifies 
the order of failover, with the second host taking over for the first host, the third 
taking over for the second, and so on. 

If all hosts are unhealthy, the operation fails either open or closed, depending 
upon your settings. 

This configuration is usually created and managed through policy. If no SOCKS- 
gateways policy applies, you can create a default sequence through the CLI. This 
single default sequence consists of a single default host (or group) plus one or 
more hosts to use if the preceding ones are unhealthy. 

To create the default sequence: 



Note: Traffic is forwarded to the first member of the list until it fails, then traffic is 
sent to the second member of list until it fails or the first member becomes healthy 
again, and so on. 



1. Select Configuration > Forwarding > SOCKS Gateways > Default Sequence. 



SOCKS Gateways | SOCKS Gateway Groups | Global Defaults Default Sequence Install SOCKS Gateway File 

- Default Fail-Over Sequence 

Available Aliases Selected Aliases 

Alias name Alias name 



test 19 



Add » 

Demote 



2. The available aliases (host and group) display in the Available Aliases pane. To 
select an alias, highlight it and click Add. 



Note: Any host or group in the default sequence is considered in use by 
policy. As a result, if you try to delete a host or group while it is in the default 
sequence, you receive an error message. You must remove the host/ group 
from the sequence first, then delete the host or group. 

3. You can use the Promote and Demote buttons to change the order of the hosts 
and groups in the sequence after you add them to the Selected Aliases pane. 

4. Click Apply. 

Related CLI Syntax to Configure SOCKS Gateways 

SGOS# (config) socks-gateways 

SGOS# (config socks-gateways) create gateway gateway_alias gateway_host 
SOCKS_port [group =group-alias] [version [=4 | =5}] [user ^username 
[password ^password | encrypted-password =encrypted-password} ] 
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SGOS# (config socks-gateways ) 
SGOS# (config socks-gateways) 
SGOS# (config socks-gateways) 
SGOS# (config socks-gateways) 
SGOS# (config socks-gateways) 
SGOS# (config socks-gateways) 



create group group_name 
delete all 

delete gateway gateway_alias 
delete group group^name 
destroy-old-passwords 
edit gateway_alias 



SGOS# (config socks-gateways gateway_alias) encrypted-pas sword 
encrypted_pas sword 

SGOS# (config socks-gateways gateway_alias) host gateway_host 
SGOS# (config socks-gateways gateway_alias) host-affinity http 
{default | none | client-ip-address | accelerator-cookie} 

SGOS# (config socks-gateways gateway_alias) host-affinity ssl 
{default | none | client-ip-address | accelerator-cookie | ssl- 
session-id} 

SGOS# (config socks-gateways gateway_alias) host-affinity other 
{default | none | client-ip-address} 

SGOS# (config socks-gateways gateway_alias) load-balance method 
{default | least-connections | none | round-robin} 

SGOS# (config socks-gateways gateway_alias) no {password | user} 
SGOS# (config socks-gateways gateway_alias) password password 
SGOS# (config socks-gateways gateway_alias) port socksport 
SGOS# (config socks-gateways gateway_alias) user username 
SGOS# (config socks-gateways gateway_alias) version {4 | 5} 

SGOS# (config socks-gateways gateway_alias) view 



SGOS# (config socks-gateways) edit group_alias 



SGOS# (config socks-gateways group_alias) {add | remove} 
gateway_alias 

SGOS# (config socks-gateways group_alias) host-affinity http 
{default | none | client-ip-address | accelerator-cookie} 

SGOS# (config socks-gateways groupalias) host-affinity ssl {default 
I none | client- ip-address | accelerator-cookie | ssl-session-id} 
SGOS# (config socks-gateways group_alias) host-affinity other 
{default | none | client-ip-address} 

SGOS# (config socks-gateways group_alias) load-balance method 
{default | domain-hash | least-connections | none | round- robin | 
url-hash} 

SGOS# (config socks-gateways group_alias) view 



SGOS# (config socks-gateways) exit 

SGOS# (config socks-gateways) failure-mode {open | closed} 

SGOS# (config socks-gateways) host-affinity http {default | none | 
client- ip-address | accelerator-cookie} gateway_or_group_alias 
-or- 

SGOS# (config socks-gateways) host-affinity ssl {default | none | 
client- ip-address | accelerator-cookie | ssl-session-id} 

gateway_or_group_alias 

-or- 

SGOS# (config socks-gateways) host-affinity other {default | client- ip- 
address | none} gateway_or_group_alias 

SGOS# (config socks-gateways) load-balance gateway {default | none | 
round-robin | least-connections} gateway_alias 

SGOS# (config socks-gateways) load-balance group {default | none | 
domain-hash | url-hash | round- robin | least-connections} group^alias 
SGOS# (config socks-gateways) no path 
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SGOS# (config socks-gateways) 
SGOS# (config socks-gateways) 
remove} gateway-alias 
SGOS# (config socks-gateways) 
SGOS# (config socks-gateways) 



path url 

sequence { add | demote | promote | 

sequence clear 
view 



Statistics 

SOCKS gateways statistics are available through the Statistics > Advanced > SOCKS 
Gateways menu item. 
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Section B: Using SOCKS Gateways Directives with Installable Lists 

To configure a SOCKS gateway, you can use the Management Console (easiest), 
the CLI, or you can create an installable list and load it on the ProxySG. To use the 
Management Console, see Section A: "Configuring a SOCKS Gateway” on page 
328. For information on installing the file itself, see "Creating a SOCKS Gateway 
Installable List" on page 342. 

The SOCKS gateways configuration includes SOCKS directives that: 

□ Names the SOCKS gateways, version, and port number 

□ Creates the SOCKS gateways groups 

□ Provide load balancing and host affinity 

□ Specifies the username 

□ Specifies the password 

Available directives are described in the table below. 



Table 13-1 SOCKS Directives 



Directive 


Meaning 


gateway 


Specifies the gateway alias and name, SOCKS port, version 
supported, usernames and password. 


group 


Creates a forwarding group directive and identifies member of 
the group. 


host affinity 


Directs multiple connections by a single user to the same group 
member. 


load balance 


Manages the load among SOCKS gateways in a group, or 
among multiple IP addresses of a gateway. 


sequence 
alias list 


Adds a space-separated list of one or more SOCKS gateways 
and group aliases. (The default sequence is the default 
forwarding rule, used for all requests lacking policy instructions 


socks fail 


In case connections cannot be made, specifies whether to abort 
the connection attempt or to connect to the origin content server. 



Syntax for the SOCKS directives are: 

gateway gateway_alias gateway_name SOCKS_port [group =group_alias] 
[version={4 | 5}] [user=username] [password=password] [encrypted- 
pas sword =encrypted_pas sword] 
group =group_alias [ gateway_alias_list ] 

host_af finity http {none | client-ip-address I accelerator-cookie} 
[ gateway_or_group_alias ] 

host_af finity ssl {none | client-ip-address I accelerator-cookie I 
ssl-session-id} [ gateway_or_group_alias ] 
host_af finity other {none I client-ip-address} 

[ gateway_or_group_alias] 
host_af finity timeout minutes 
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load_balance group {none | domain-hash | ur 1-hash | round-robin | 
least-connections} [ group_alias ] 

load_balance gateway {none | round-robin | least-connections} 

[gateway_alias] 

sequence alias_list 

socks_fail {open | closed} 

For more information on SOCKS gateway directives, continue with the next 

section. For information on: 

□ group directives, continue with "Creating SOCKS Gateways Groups Using 
Directives" on page 339 

□ load balance directives, continue with "Configuring Load Balancing 
Directives" on page 339 

□ host affinity directives, continue with "Configuring Host Affinity 
Directives" on page 340 

□ socks_faii directives, continue with "Setting Fail Open/ Closed" on page 339 

□ sequence directives, continue with "Creating a Default Sequence" on page 341 

Configuring SOCKS Gateways Using Directives 

SOCKS gateways can be configured using the gateways suboptions in the table 

below. 



Table 13-2 SOCKS Gateways Syntax 



Command 


Suboptions 


Description 


gateway 




Configures the SOCKS gateway. 




gateway alias 


A meaningful name that is used for policy rules. 




gateway name 


The IP address or name of the gateway where 
traffic is directed. The gateway name must DNS 
resolve. 




SOCKS_port 


The port number of the SOCKS gateway. 




version={4 | 5} 


The version that the SOCKS gateway can 
support. 




user =username 


(Optional, if you use v5) The username of the 
user. It already must exist on the gateway. 




password ^password 


(Optional, if you use v5) The password of the 
user on the SOCKS gateway. It must match the 
gateway's information. 




encrypted- 

pas sword ^encrypted 

password 


(Optional, if you use v5) The encrypted 
password of the user on the SOCKS gateway. It 
must match the gateway's information. 



338 



Chapter 13: SOCKS Gateway Configuration 



Section B: Using SOCKS Gateways Directives with Installable Lists 

Example 

gateway Sec_Appl 10.25.36.47 1022 version=5 user=username 
password ^password 

Creating SOCKS Gateways Groups Using Directives 

The SOCKS gateway groups directive has the following syntax: 

group group_name gateway_alias_l gateway_alias_2 . . . 

where group_name is the name of the group, and gateway_alias_l, 
gateway_aiias_2, and so forth are the gateways you are assigning to the SOCKS 
gateways group. 

Setting Special Parameters 

After you configure the SOCKS gateways and groups, you might need to set other 
special parameters to fine tune gateways. You can configure the following 
settings: 

□ "Setting Fail Open/ Closed" 

□ "Configuring Load Balancing Directives" on page 339 

□ "Configuring Host Affinity Directives" on page 340 

Setting Fail Open/Closed 

Using directives, you can determine if the SOCKS gateways fails open or closed or 
if an operation does not succeed. 

The syntax is: 

socks_fail {open | closed} 

where the value determines whether the SOCKS gateways should fail open or 
fail closed if an operation does not succeed. Fail open is a security risk, and 
fail closed is the default if no setting is specified. This setting can be 
overridden by policy, using the socKS gateway. faii^open (yes | no) property. 

Examples 

socks_fail open 

Configuring Load Balancing Directives 

Load balancing shares the load among a set of IP addresses, whether a group or a 
gateway with multiple IP addresses. 

The syntax is: 

load_balance group {none | domain-hash | ur 1-hash | round- robin | 
least-connections} [ group^alias ] 

load_balance gateway {none I round- robin | least-connections} 
[gateway_alias] 
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Table 13-3 Load Balancing Directives 



Command 


Suboptions 


Description 


load balance 
group 


{none | domain-hash | url- 
hash | round-robin | 
least-connections } 

[group alias] 


If you use group for load balancing, 
you can set the suboption to none or 
choose another method. If you do 
not specify a group, the settings 
apply as the default for all groups. 


load balance 
gateway 


{none | round-robin | 
least-connections } 

[ gateway alias] 


If you use gateway for load 
balancing, you can set the suboption 
to none or choose another method. 
If you do not specify a gateway, the 
settings apply as the default for all 
gateways. 



Example 

load_balance gateway least_connections 

Configuring Host Affinity Directives 

Host affinity is the attempt to direct multiple connections by a single user to the 
same group member. 

The syntax is: 

host_af finity http {none | client-ip-address | accelerator-cookie} 

[ gateway_or_group_alias ] 

host_af finity ssl {none | client-ip-address | accelerator-cookie | 
ssl-session-id} [ gateway_or_group_alias ] 
host_af finity other {none | client-ip-address} 

[ gateway_or_group_alias ] 
host_af finity timeout minutes 



Table 13-4 Commands to Configure Host Affinity Directives 



Command 


Suboption 


Description 


host affinity 
http 


{accelerator-cookie | 
client-ip-address | none} 
[ gateway or group alias] 


Determines which HTTP host- 
affinity method to use 
(accelerator cookie or client- 
ip- address), or you can specify 
none. If you do not specify a 
gateway or group, the settings 
apply as the default for all gateways 
or groups. 
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Table 13-4 Commands to Configure Host Affinity Directives (Continued) 



Command 


Suboption 


Description 


host affinity 
ssl 


{accelerator-cookie | 
client-ip-address | none 
I ssl-session-id} 

[ gateway or group alias] 


Determines which SSL host-affinity 
method to use (accelerator 
cookie, client-ip-address, or 
ssl-session-id), or you can 
specify none. If you do not specify a 
gateway or group, the settings 
apply as the default for all gateways 
or groups. 


host affinity 
other 


other {none I client-ip- 
address } 

[ gateway or group alias] 


Determines whether TCP tunnel 
and Telnet is used. Determines 
whether to use the client-ip- 
address host-affinity method or 
specify none. If you do not specify a 
gateway or group, the settings 
apply as the default for all gateways 
or groups. 


host affinity 
timeout 


minutes 


Determines how long a user's IP 
address, SSL ID, or cookie remains 
valid when idle. 



Example 

host_af finity ssl accelerator-cookie 10.25.36.48 
host_af finity timeout 5 

Creating a Default Sequence 

The default sequence is the default SOCKS gateways rule, used for all requests 
lacking policy instructions. Failover is supported if the sequence (only one is 
allowed) has more than one member. 



Note: Creating the default sequence through the CLI is a legacy feature. You can 
set up sequences by using policy alone. The default sequence (if present) is 
applied only if no applicable command is in policy. 

For information on using VPM, refer to Volume 6: The Visual Policy Manager and 
Advanced Policy; for information on using CPL, refer to Volume 10: Content Policy 
Language Guide. 



A default failover sequence works by allowing healthy SOCKS gateways to take 
over for an unhealthy gateway (one that is failing its DNS resolution or its health 
check). The sequence specifies the order of failover, with the second gateway 
taking over for the first gateway, the third taking over for the second, and so on). 

If all gateways are unhealthy, the operation fails either open or closed, depending 
upon your settings. 
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This configuration is generally created and managed through policy. If no 
forwarding policy applies, you can create a default sequence through the CLI. 
This single default sequence consists of a single default gateway (or group) plus 
one or more gateways to use if the preceding ones are unhealthy 

The syntax is: 

sequence alias_list 

where aiias_iist is a space-separated list of one or more SOCKS gateways 
and group aliases. 

Example 

sequence gateway_alias 

Creating a SOCKS Gateway Installable List 

You can create and install the SOCKS gateway installable list with the following 
methods: 

□ Use the Text Editor, which allows you to enter directives (or copy and paste 
the contents of an already-created file) directly onto the ProxySG. 

□ Create a local file on your local system; the ProxySG can browse to the file and 
install it. 

□ Use a remote URL, where you place an already-created file on an FTP or 
HTTP server to be downloaded to the ProxySG appliance. 

When the SOCKS gateway installable list is created, it overwrites any previous 
SOCKS gateway configurations on the ProxySG. The installable list remains in 
effect until it is overwritten by another installable list; it can be modified or 
overwritten using Management Console or CLI commands. 



Note: During the time that a SOCKS gateways installable list is being compiled 
and installed, SOCKS gateways might not be available. Any transactions that 
come into the appliance during this time might not be forwarded properly. 



Installation of SOCKS gateways installable-list configuration should be done 
outside peak traffic times. 

To create a SOCKS gateway installable list: 

1. Select Configuration > Forwarding > SOCKS Gateways > Install SOCKS Gateway File. 

2. If you use a SOCKS gateway server for the primary or alternate forwarding 
gateway, you must specify the ID for the Identification (Ident) protocol used 
by the SOCKS gateway in SOCKS server handshakes. The default is bluecoat 

SYSTEMS . 

3. From the drop-down list, select the method used to install the SOCKS 
gateway configuration; click Install. 
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• Remote URL: 

Enter the fully-qualified URL, including the filename, where the 
configuration is located. To view the file before installing it, click View. 
Click Install. Examine the installation status that displays; click OK. 

• Local File: 

Click Browse to bring up the Local File Browse window. Browse for the file 
on the local system. Click Install. When the installation is complete, a 
results window opens. View the results, close the window, click Close. 

• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the 
installation is complete, a results window opens. View the results, close 
the window, click Close. 

4. Click Apply. 

Related CLI Syntax to specify the SOCKS Gateway Machine ID 

SGOS# (config) socks-machine-id machine_ID 
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This chapter discusses Blue Coat health checks, which enable you to determine 
the availability of external networking devices and off-box services. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ Section A: "Overview" on page 346 

□ Section B: "About Blue Coat Health Check Components" on page 349 

□ Section C: "Configuring Global Defaults" on page 355 

□ Section D: "Forwarding Host and SOCKS Gateways Health Checks" on 
page 366 

□ Section E: "DNS Server Health Checks" on page 373 

□ Section F: "Authentication Health Checks" on page 377 

□ Section G: "Virus Scanning and Content Filtering Health Checks" on page 
380 

□ Section H: "Managing User-Defined Health Checks" on page 386 

□ Section I: "Viewing Health Check Statistics" on page 397 

□ Section J: "Using Policy" on page 403 

□ Section K: "Related CLI Syntax to Configure Health Checks" on page 404 
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Section A: Overview 

The ProxySG performs health checks to test for network connectivity and to 
determine the responsiveness of external resources. Examples of external 
resources include — DNS servers, forwarding hosts, SOCKS gateways, 
authentication servers, ICAP services (for example, anti-virus scanning services), 
and Websense off-box services. 

The ProxySG automatically generates health checks based on: 

□ Forwarding configuration 

□ SOCKS gateways configuration 

□ DNS server configuration 

□ ICAP service configuration 

□ Websense off-box configuration 

□ Authentication realm configuration 

□ Whether Dynamic Real-Time Rating (DRTR) is enabled 

You also can create user-defined health checks, including a composite health 
check that combines the results of multiple other health check tests. For 
information on health check types, see Section B: "About Blue Coat Health Check 
Components" on page 349. 

Health checks fall into three broad categories: 

□ Determining if the IP address can be reached. Health check types that fall into 
this category are: 

• Forwarding hosts 

• SOCKS gateways 

• User-defined host health checks 

□ Determining if a service is responsive. Health check types that fall into this 
category are: 

• Authentication servers 

• DNS server 

• Dynamic Real-Time Rating (DRTR) service 

• ICAP services 

• Websense off-box services 

□ Determining if a group is healthy. Group tests are compilations of individual 
health checks, and the health of the group is determined by the status of the 
group members. Health check types that fall into this category are: 

• Forwarding groups 

• SOCKS gateway groups 
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• ICAP service groups 

• Websense off-box service groups 

• User-defined composite health checks 

Information provided by health checks allows you to accomplish the following: 

□ Detect potential network issues before they become critical. For example, if 
the health check for an individual host fails, the ProxySG sends an alert (using 
e-mail, SNMP, or by writing to an event log) to the designated recipients, if 
configured. To configure recipients, see Section C: "Configuring Global 
Defaults" on page 361. 

□ Track response times and report failures. For example, if the DNS server 
performance suffers a reduction, the users experience response time delays. 
The DNS health check records the average response time (in milliseconds) and 
allows you to interpret the reason for the performance reduction. Should the 
DNS server become unavailable, the failed health check triggers an alert. 

Furthermore, the ProxySG uses health check information to accomplish the 
following: 

□ When combined with failover configurations, health checks redirect traffic 
when a device or service failure occurs. For example, a health check detects an 
unhealthy server and a forwarding rule redirects traffic to a healthy server or 
proxy. 

□ Monitor the impact of health check states on the overall health of the 
appliance. Health check status is a metric in calculating the overall health of 
the ProxySG and is reflected in the health monitor, which is located at the 
upper right hand corner of the Management Console. For example, if a health 
check fails, the health monitor displays Health: Warning. You can click on the 
health monitor link to navigate and view the cause for the warning. 

Executing an instant health check 

Although the ProxySG automatically executes health checks, you can rim an 
instant health check from the Configuration > Health Checks > General > Health Checks 
tab by selecting the health check and clicking Perform health check. You can also 
view the health check state on the Statistics > Health Check tab. 

Background DNS Resolution 

Background testing of the DNS resolutions is done on all resolvable hostnames 
used in the health check system, including forwarding hosts, DRTR, and SOCKS 
gateways. That way, the list of IP addresses associated with a hostname stays 
current. The DNS system is checked whenever the time-to-live (TTL) value of the 
DNS entry expires. 



Note: If a hostname consists of a dotted IP address, no DNS resolution is 
performed. 
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When a host is resolved by DNS to multiple IP addresses, health checks keep 
those addresses current through background updates. You can configure the 
timing for the updates on the Configuration > Health Checks > Background DNS tab. 
After the test or tests are conducted for each IP address, the results are combined. 
If the result for any of the resolved IP addresses is healthy, then the host is 
considered healthy because a healthy connection to that target can be made. 
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Section B: About Blue Coat Health Check Components 

Health checks have two components: 

□ Health check type: The kind of device or service the specific health check tests. 
The following types are supported: 

• Forwarding host and forwarding group 

• SOCKS gateway and SOCKS gateway group 

• DNS servers 

• External Authentication servers 

• ICAP service and ICAP service group 

• Websense off-box service and Websense off-box service group 

• Dynamic Real-Time Rating Service 

• User-defined host and composite health checks 

□ Health check tests: The method of determining network connectivity, target 
responsiveness, and basic functionality 

• Health checks (external targets) 

• Authentication 

• Internet Control Message Protocol (ICMP) 

• DNS 

• TCP 

• SSL 

• HTTP 

• HTTPS 

• ICAP 

• Websense 

• DRTR 

• Health checks (group targets) 

• Groups 

• Composite 

Note: Some health checks (such as forwarding hosts and SOCKS 
gateways) can be configured to report the result of a composite health 
check instead of their own test. 



349 



Volume 5: Advanced Netzvorking 



Section B: About Blue Coat Health Check Components 

Some health check types only have one matching test, while others have a 
selection. For more information about health check types and tests, see Table 14-1 
on page 351. 

Health Check Types 

Most health checks are automatically created and deleted when the underlying 
entity being checked is created or deleted. When a forwarding host is created, for 
example, a health check for that host is created. Later, if the forwarding host is 
deleted, the health check for it is deleted as well. User interaction is not required, 
except to change or customize the health check behavior if necessary. However, if 
a health-check is referenced in policy, you cannot delete the corresponding host or 
the health check itself until the reference in policy is deleted. 

In addition to the health checks that are automatically generated, rim, and 
deleted. Blue Coat also supports two kinds of user-defined health checks. These 
health checks are manually created, configured, and deleted. 

□ Composite health checks: A method to take the results from a set of health 
checks (automatically generated or user-defined health checks) and combine 
the results. 

□ Host health checks: A method to test a server, using a selection of ICMP, TCP, 
SSL, HTTP, and HTTPS tests. 



Note: Although a host health check tests an upstream server, it can also be 
used to test whether a proxy is working correctly. To test HTTP/HTTPS 
proxy behavior, for example, you can set up a host beyond the proxy, and 
then use forwarding rules so the health check passes through the proxy to the 
host, allowing the proxy to be tested. 



User-defined health checks allow you to test for attributes that the ProxySG does 
not test automatically. For example, for a forwarding host, you could perform 
three user-defined tests — an HTTP test, an HTTPS test, and a TCP test of other 
ports. Then, you can set up a composite health check that combines the results of 
these user-defined tests to represent the health of the forwarding host. The 
ProxySG reports the status of the (user-defined) composite health check as the 
forwarding host's health, instead of the default forwarding host health check. 

All health check types are given standardized names, based on the name of the 
target. For example: 

□ Forwarding hosts and groups have a prefix of fwd 

□ DNS servers have a prefix of dns 

□ SOCKS gateways and gateway groups have a prefix of socks 

□ Authentication realms have a prefix of auth 

□ External services have prefixes of icap, ws, and drtr 

□ User-defined or composite health checks have a prefix of user 
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Health Check Tests 

Based on the health check type, the ProxySG periodically tests the health status, 
and thus the availability of the host. You can configure the time interval between 
tests. If the health check test is successful, the appliance considers the host 
available. 

The health check tests are described in the table below. 



Table 14-1 Health Check Tests 



Health Check 
Test 


Description 


Used With 
Health Check 
Type 


Response Times 


The minimum, maximum, and average 
response times are tracked, with their values 
being cleared whenever the health check 
changes state. 


All 


ICMP Test (Layer 
3) 


The basic connection between the ProxySG and 
the origin server is confirmed. The server must 
recognize ICMP echoing, and any intervening 
networking equipment must support ICMP. 
The ProxySG appliance sends a ping (three 
ICMP echo requests) to the host. 

ICMP tests do not support policy for SOCKS 
gateways or forwarding. 


Forwarding 
hosts, SOCKS 
gateways, or 
user-defined 
hosts 


TCP Socket 
Connection Test 
(Layer 4) 


A TCP test establishes that a TCP layer 
connection can be established to a port on the 
host. Then the connection is dropped. 

TCP tests for a SOCKS gateway do not support 
policy for SOCKS gateways or forwarding. 

TCP tests for a forwarding host or a user- 
defined health check support SOCKS gateways 
policy but not forwarding policy. 


Forwarding 
hosts, SOCKS 
gateways, or 
user-defined 
hosts 


SSL Test 


A connection is made to a target and the full 
SSL handshake is conducted. Then, much like 
the TCP test, the connection is dropped. 

For a forwarding host, a terminating HTTPS 
port must be defined or the test fails. 

SSL tests for a forwarding host or a user- 
defined health check support SOCKS gateways 
policy. The SSL tests do not support forwarding 
policy. 

An SSL test executes the SSL layer in policy and 
obeys any settings that apply to server-side 
certificates, overriding any settings obtained 
from a forwarding host. 


Forwarding 
hosts or user- 
defined hosts 
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Table 14-1 Health Check Tests (Continued) 



Health Check 
Test 


Description 


Used With 
Health Check 
Type 


HTTP/HTTPS 
Tests for Servers 
and Proxies 


HTTP /HTTPS tests execute differently 
depending on whether the upstream target is a 
server or a proxy. For a forwarding host, the 
server or a proxy is defined as part of the 
forwarding host configuration. For a user- 
defined health check, the target is always 
assumed to be a server. 

For a server: 

• The HTTP test sends an HTTP GET request 
containing only the URL path to an HTTP 
port. 

• The HTTPS test sends an HTTPS GET request 
containing only the URL path over an SSL 
connection to a terminating HTTPS port. 

If an appropriate port is not available on the 
target, the test fails. 

For a proxy: 

• The HTTP test sends an HTTP GET request 
containing the full URL to an HTTP port. 

• Since a server is required to terminate 
HTTPS, the HTTPS test sends an HTTP 
CONNECT request to the HTTP port. 

If an appropriate HTTP port is not available on 
the proxy, either test fails. 

An HTTP/HTTPS test requires a full URL for 
configuration. 

The HTTP /HTTPS tests for a forwarding host 
support SOCKS gateway policy but not 
forwarding policy. 

The HTTP/HTTPS tests for a user-defined 
health check support SOCKS gateway and 
forwarding policy. 

An HTTPS test executes the SSL layer in policy 
and obeys any settings that apply to server-side 
certificates, overriding any settings obtained 
from a forwarding host. 


Forwarding 
hosts or user- 
defined hosts. 


HTTP/HTTPS 

Authentication 


For HTTP /HTTPS tests, you can test 
authentication using a configured username 
and password. The passwords are stored 
securely in the registry. 


Forwarding 
hosts or user- 
defined hosts. 
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Table 14-1 Health Check Tests (Continued) 



Health Check 
Test 


Description 


Used With 
Health Check 
Type 


HTTP/HTTPS 

Allowed 

Responses 


For an HTTP or HTTPS test, this is the set of 
HTTP response codes that indicate success. The 
default is to accept only a 200 response as 
successful. You can specify the sets of response 
codes to be considered successful. 


Forwarding 
hosts or user- 
defined hosts. 


External Services 
Tests 


The tests for external services are specialized 
tests devised for each particular kind of external 
service. The health check system conducts 
external service tests by sending requests to the 
external services system, which reports back a 
health check result. 


ICAP, Websense 
off-box, DRTR 
service. 


Group 


Individual tests that are combined for any of the 
four different available groups (forwarding, 
SOCKS gateways, ICAP services, and Websense 
off -box). If any of the members is healthy, then 
the group as a whole is considered healthy. 

Note: Blue Coat supports a composite test, 
used only with composite (user-defined) 
health checks, that is similar to a group test 
except that, by default, all members must be 
healthy for the result to be healthy. 

These settings are configurable. 

By default, group health tests are used for two 
purposes: 

• Monitoring and notification 

• Policy 


Forwarding 
groups, SOCKS 
gateways 
groups, and 
ICAP and 
Websense off- 
box external 
service groups. 


DNS Server 


The DNS server maps the hostname, default is 
www.bluecoat.com, to an IP address. The health 
check is successful if the hostname can be 
resolved to an IP address by the DNS server. 


DNS 


Authentication 


Authentication health checks assess the realm's 
health using data maintained by the realm 
during active use. Authentication health checks 
do not probe the authentication server with an 
authentication request. 


Authentication 



See Also: 

□ "To edit forwarding and SOCKS gateways health checks:" on page 367 

□ "To edit forwarding or SOCKS gateway group health checks:" on page 369 

□ "To edit a DNS server health check:" on page 373 
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□ "To edit an authentication health check:" on page 377 

□ "To edit virus scanning and content filtering tests:" on page 380 

□ "To edit Websense off-box or ICAP group tests:" on page 383 

□ "To create a user-defined host health check:" on page 388 

□ "To create a user-defined composite health check:" on page 392 
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Section C: Configuring Global Defaults 

In general, all health checks are initially configured to use global defaults. 



Note: The DRTR service is initially configured to override two of the default 
settings. The healthy interval is set to 10800 seconds (3 hours), and a failure 
trigger is set to 1. 



About Health Check Defaults 

You can change the defaults on most health checks. These defaults override global 
defaults, which are set from the Configuration > Health Checks > General > Default 
Settings tab. 

You can edit health check intervals, severity, thresholds, and notifications for 
automatically generated health checks in two ways: 

□ Setting the global defaults. These settings affect all health checks, unless 
overridden by explicit settings. 

□ Setting explicit values on each health check. 

The default health check values are: 

□ Ten seconds for healthy and sick intervals (an interval is the period between 
the completion of one health check and the start of the next health check). 

□ One for healthy and sick thresholds. A healthy threshold is the number of 
successful health checks before an entry is considered healthy; a sick threshold 
is the number of unsuccessful health checks before an entry is considered sick. 

□ Warning for the severity notification, which governs the effect that a health 
check has on the overall health status of the ProxySG. 

□ Disabled for logging health check status using e-mails, event logs, or SNMP 
traps. 

To configure the settings, continue with "Changing Health Check Default 
Settings" on page 357. To configure notifications, continue with "Configuring 
Health Check Notifications" on page 361. 

Enabling and Disabling Health Checks 

You can enable or disable health checks and configure them to report as healthy or 
unhealthy during the time they are disabled. 

Setting a health check as disabled but reporting healthy allows the ProxySG to use 
the device or service without performing health checks on it. If, for example, you 
have configured a forwarding host on the ProxySG, a health check for the 
forwarding host is automatically created. If you then configure the health check as 
disabled reporting healthy, the ProxySG considers the forwarding host as healthy 
without performing periodic health checks on it. 
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If the case of a group health check that is disabled but reporting healthy, all 
members of the group are treated as healthy regardless of the status of the 
members' individual health checks. 



Note: Individual health checks for members of a group remain active; they can be 
used apart from the group. 



Setting a health check as disabled but reporting sick is useful to remove an 
upstream device for servicing, testing, or replacement. This setting takes the 
device offline after it completes processing pre-existing traffic. Then the device 
can be safely disconnected from the network without altering any other 
configuration. 

You cannot enable or disable all health checks at once. 

Related CLI Syntax to Enable and to Disable a Health Check 

# (config health-check) enable alias_name 

Enables the health check. 

# (config health-check) disable { healthy alias^name | sick alias_name} 

Disables the specified health check and sets it to report healthy or unhealthy. 

Notifications and SNMP Traps 

If you configure notifications, the ProxySG sends all or any of e-mail, SNMP, and 
event log notifications when a change of health check state occurs. By default, all 
notifications are disabled. 

On the ProxySG you can: 

□ Globally change notifications for all health checks 

□ Explicitly change notifications for specific health checks 

□ Enable notifications of transitions to healthy 

□ Enable notifications of transitions to unhealthy 

A transition to healthy occurs as soon as the target is sufficiently healthy to be sent 
a request, even though the target might not be completely healthy. For example, if 
you have multiple IP addresses resolved and only one (or a few) is responsive, the 
group is classified as healthy and the health status might be Ok with errors or Ok for 
some IP’s. For some health check groups, like forwarding hosts, you can configure 
a minimum number of members that must be healthy for the group to be healthy. 

In the event log, status changes can be logged as either informational or severe 
logs. In addition to the overall health of the device, you can enable notifications 
for each resolved IP address of a target device (if applicable). 

An SNMP trap can also be used for notification of health check state changes. It is 
part of the Blue Coat Management Information Base (MIB) as biueCoatMgmt 7.2.1. 
For information on configuring SNMP, see Volume 9: Managing the Blue Coat 
ProxySG Appliance. 
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Guidelines for Setting the Severity of a Health Check 

Severity indicates how a failed health check affects the overall health of the 
device. The severity option links Health Checks and Health Monitoring. The health 
monitor displays the overall health of the device after considering the health 
check status in conjunction with other health monitoring metrics. For information 
on the health monitoring metrics, see Volume 9: Managing the Blue Coat ProxySG 
Appliance. 



Note: Severity of a health check is pertinent only when a health check fails. 



The ProxySG allows you to configure the severity option to Critical, Warning and 
No effect. Set the severity of a health check to: 

□ Critical: If the success of a health check is crucial to the health of the device. If 
the health check then reports unhealthy, the overall health status becomes 

Critical. 

□ Warning: If a failed health check implies an emerging issue and the 
administrator must be alerted when the health check state transitions from 
healthy to unhealthy. Consequently, when the health check reports unhealthy, 
the overall health status transitions to Warning. 

□ No effect: If the success of a health check bears no impact on the health of the 
device. Should the health check transition to unhealthy, the overall health 
status of the device retains its current status and does not change. 

For example, if the severity on an external service health check for Websense — 
ws.ws_1, is set to severity level Critical and the health check fails, the overall health 
status of the device will transition to Health: Critical. 

To change notifications, continue with "Configuring Health Check Notifications" 
on page 361. 

Changing Health Check Default Settings 

You can modify the default settings for all health checks on the Configuration > 
Health Checks > General > Default Settings tab or you can override the default settings 
for a health check on the Configuration > Health Checks > General > Health Checks tab, 
selecting the health check, and clicking Edit. Explicit health settings override the 
global defaults. 

To change the global default settings: 

1. Select Configuration > Health Checks > General > Default Settings. 
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Health Checks Default Settings 


Default Notifications 




- Default Settings 










Healthy interval: 


10 


seconds 






Healthy threshold: 


1 


□ 






Sick interval: 


10 


seconds 






Sick threshold: 


1 


□ 






|~1 Failure trigger threshold: 


l» 


1 






□ Response time threshold: 




milliseconds 





2. Change the settings as appropriate: 



a. Specify the healthy interval, in seconds, between health checks. The 
default is 10. The healthy interval can be between 1 second and 
31536000 seconds (about one year). 

b. Specify the healthy threshold for the number of successful health 
checks before an entry is considered healthy. Valid values can be 
between 1 and 65535. The default is 1 . 

c. Specify the sick interval, in seconds, between health checks to the 
server that has been determined to be unhealthy or out of service. The 
default is 10. The sick interval can be between 1 second and 31536000 
seconds (about 1 year). 

d. Specify the sick threshold, or the number of failed health checks before 
an entry is considered unhealthy. Valid values can be between 1 and 
65535. The default is 1. 

e. Specify the failure threshold for the number of failed connections to 
the server before a health check is triggered. Valid values can be 
between 1 and 2147483647. It is disabled by default. 

The failures are reported back to the health check as a result of either a 
connection failure or a response error. The number of these external 
failures is cleared every time a health check is completed. If the number of 
failures listed meets or exceeds the threshold and the health check is idle 
and not actually executing, then the health of the device or service is 
immediately checked. 

f. Specify the maximum response time threshold, in milliseconds. The 
threshold time can be between 1 and 65535. 

3. Click Apply. 

To override default settings for a targeted health check: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the test you want to modify. 

3. Click Edit. The example below uses a SOCKS gateway. 
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4a 



4b 

4c 

4d 

4e 

4f 

4g 



- Edit SOCKS Gateways Health Check 

Name: socks, test 19 

Type of test: yep v 

Enabled state: ® Enabled 

O Disabled, reporting as healthy 
O Disabled, reporting as sick 

Port: ® Use configured port 

O Use port 

- Override Defaults 

1— i=t Override J the default settings 




4. To substitute special values for this test: 



a. Click Override the default settings. The Override Default Settings dialog 
displays. Configure the override options. You can cancel your choices 
by clicking Clear all overrides. 

b. Specify the healthy interval, in seconds, between health checks to the 
server. The default is 10. The healthy interval is between 1 second and 
31536000 seconds (about one year). 

c. Specify the healthy threshold for the number of successful health 
checks before an entry is considered healthy. Valid values are 1-65535. 
The default is 1 . 



d. Specify the sick interval, in seconds, between health checks to the 
server that has been determined to be unhealthy or out of service. The 
default is 10. The sick interval is between 1 second and 31536000 
seconds (about 1 year). 

e. Specify the sick threshold, or the number of failed health checks before 
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an entry is considered unhealthy. Valid values are 1-65535. The default 
is 1. 

f. Specify the failure trigger for the number of failed connections to the 
server before a health check is triggered. Valid values are between 1 
and 2147483647. 

The failures are reported back to the health check as a result of either a 
connection failure or a response error. The number of these external 
failures is cleared every time a health check is completed. If the number of 
failures listed meets or exceeds the threshold, and the health check is idle 
and not actually executing, then the health of the device or service is 
immediately checked. 

g. Specify the maximum response time threshold, in milliseconds. The 
threshold time can be between 1 and 65535. 

h. Click OK to close the dialog. 

5. Click Apply. 

Related CLI Syntax to Modify Default Settings Globally 

#(config health-check) default failure-trigger {none | count} 

Configures defaults for the failure-trigger options. 

#(config health-check) default interval {healthy secondsl sick 
seconds} 

Configures defaults for interval options. 

#(config health-check) default threshold {healthy count | response- 
time milliseconds | sick count } 

Configures defaults for threshold options. 

Related CLI Syntax to Modify Default Settings for a Targeted Health Check 

# (config health-check) edit alias_name 

Allows you to configure options for the specified health check. 

# (config health-check alias_name) clear-statistics 

Clears statistics for this health check. 

# (config health-check alias_name) failure-trigger {default | none | 
count } 

Configures options for the failure-trigger. 

# (config health-check alias_name) interval {healthy {default | 
seconds} | sick {default | seconds}} 

Configures intervals before the health check is re-run. The intervals can be 
different for health checks that are reporting healthy and health checks that 
are reporting sick. 

# (config health-check alias_name) perform-health-check 

Starts the health check immediately and reports the result. 
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#(config health-check alias_name) threshold {healthy {default | count } 

| response- time {default | none | milliseconds} | sick {default | 

count } } 

Sets the level when health checks will report healthy or sick. 

#(config health-check aliasname) use-defaults 

Resets the defaults of the health check to use the global defaults instead of any 
explicitly set values. 

# (config health-check alias_name) exit 

Exits the health check editing mode. 

Configuring Health Check Notifications 

The ProxySG allows you to configure notifications that alert you to changes in 
health status and to emerging issues. By default, notifications for health check 
events and status are disabled. 

You can set up health check notifications: 

□ Globally on the Configuration > Health Checks > General > Default Notifications tab 

□ Explicitly, for a health check, on the Configuration > Health Checks > General > 
Health Checks tab, selecting the health check, and clicking Edit. 

Explicit health settings override the global defaults. 

To configure health check notifications globally: 

1. Select Configuration > Health Checks > General > Default Notifications. 

2. Select the Severity level for the health check. 

• Critical: If the health check fails, the device is in critical condition 

• Warning: If the health check fails, the device needs to be monitored and 
the health check status displays as Warning. This is the default setting. 

• No effect: The health check has no impact on the overall health of the 
device. 
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Health Checks | Default Settings Default Notifications 

r Default Notifications 

Severity: No effect v 

E-mail notification 

[~1 Notify on a transition to healthy 
O Notify on a transition to sick 
0 Notify for each IP address 
Event logging 

d Log a transition to healthy as: 

1 Log a transition to sick as: 

@ Log for each IP address 
SNMP traps 

d Notify on a transition to healthy 
d Notify on a transition to sick 
d Notify for each IP address 

3. Select the options to enable notifications: 

a. E-mail notification: Select the appropriate check boxes to enable the e- 
mail notifications you require. Recipients are specified in Maintenance > 
Event Logging > Mail. 

b. Event logging: Select the appropriate options to enable the event logging 
you require. Messages can be logged as either informational or severe. 

c. SNMP traps: Select the situations for which you require SNMP traps to 
be sent. 

4. Click Apply. 

To override the default notifications for a targeted health check: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the test you want to modify. 

3. Click Edit. The Edit dialog displays. The example below uses a forwarding 
host. 

4. To change default notifications for this test, click Override the default notifications. 
By default, notifications are not sent for any health checks. 
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5. Select the options to override. You can cancel your choices by clicking Clear all 
overrides. 

a. Severity: Select the severity option as required. 

• Critical: If the health check fails, the device is in critical condition 

• Warning: If the health check fails, the device needs to be monitored 
and the health check status displays as Warning. This is the default 
setting. 
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• No effect: The health check has no impact on the overall health of the 
device. 

b. Override E-mail notification: Select the appropriate check boxes to enable 
the e-mail notifications you require. Specify recipients in Maintenance > 
Event Logging > Mail. 

c. Event logging: Select the appropriate check boxes to enable the event 
logging you need. Messages can be logged as either informational or 
severe. 

d. SNMP traps: Select the situations in which you want SNMP traps to be 
sent. 

e. Click OK to close the override dialog 

f. Click OK to close the edit dialog. 

6. Click Apply. 

Related CLI Syntax to Modify Default Notifications Globally 

#(config health-check) default e-mail {healthy {enable Idisable} | 
report-all-ips { enable | disable } | sick {enable | disable } } 

Configures defaults for e-mail notifications. 

#(config health-check) default event-log {healthy {disable 
| information | severe} | report-all-ips {enable Idisable} | sick 
{disable | information | severe}} 

Configures defaults for event-log notifications. An informational or a severe 
event-log message is logged depending on the setting chosen. 

#(config health-check) default snmp {healthy {enable Idisable} | 
report-all-ips {enable Idisable} | sick {enable Idisable}} 

Configures defaults for snmp notifications. 

#(config health-check) default severity { critical | no-effect | warning } 

Configures default severity for all health checks. 

Related CLI Syntax to Modify Default Notifications for a Targeted Health 
Check 

# (config health-check) edit alias_name 

Allows you to configure options for the specified health check. 

# (config health-check alias_name) severity { critical | no-effect I default 
I warning } 

Configures default severity for the health check. 

# (config health-check alias^name) e-mail {healthy {enable Idisable | 
default} | report-all-ips {enable Idisable default} | sick {enable | 
disable | default } } 

Configures e-mail notifications for the health check. 
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#(config health-check alias_name) event-log {healthy {disable | 
information! severe}! report-all-ips {enable | disable} | sick { 
disable | information | severe } } 

Configures event-log notifications for the health check. An informational or a 
severe event-log message is logged depending on the setting chosen. 

#(config health-check alias_name) snmp {healthy {enable Idisable} | 
report-all-ips { enable | disable } | sick {enable | disable } } 

Configures snmp notifications for the health check 

#(config health-check aliasname) use-defaults 

Resets the defaults of the health check to use the global defaults instead of any 
explicitly set values. 
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Section D: Forwarding Host and SOCKS Gateways Health Checks 

Before you can edit forwarding or SOCKS gateways health check types, you must 
configure forwarding hosts or SOCKS gateways. For information about 
configuring forwarding, see Chapter 8: "Configuring the Upstream Network 
Environment" on page 131; for information about configuring SOCKS gateways, 
see Chapter 13: "SOCKS Gateway Configuration" on page 32 7. 

This section discusses managing the automatically generated forwarding host 
and SOCKS gateway health checks. 

Forwarding Hosts and SOCKS Gateways Configurations 

The forwarding host health check configuration defines whether the target being 
tested is a server or a proxy, which ports are available, and provides the setting for 
the server certificate verification. 

The SOCKS gateways health check configuration defines the SOCKS port, the 
version (4 or 5), and possibly a username and password. 

Forwarding Hosts Health Checks 

The default for a newly created forwarding host is a TCP health check using the 
first port defined in the forwarding host's port array (typically the HTTP port). 
You can change the port setting. The TCP test can support SOCKS gateway policy. 
The URL uses the forwarding host hostname, such as: 

tcp : / /gateway_name : port/ 

SOCKS Gateways Health Checks 

The default for a newly created SOCKS gateway is a TCP health check using the 
SOCKS port in the SOCKS gateways configuration. 

Forwarding and SOCKS Gateways Groups Health Checks 

Specific tests are not done for groups. Health check test results are determined 
from examining and combining the health of the group members. 



Note: You can create groups in the Configuration > Forwarding > Forwarding Hosts tab 
or Configuration > Forwarding > SOCKS Gateways tab. 



By default, if any of the members of the group are healthy, then the group is 
considered healthy. You can specify the number of group members that must be 
healthy for the group to be considered healthy. 

Editing Forwarding and SOCKS Gateways Health Checks 

You can edit, but not delete, the forwarding and SOCKS gateway tests and 
groups. The settings you can change are: 

□ Enable or disable the health check 
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□ Override default notifications 

□ Select the type of test 

□ Specify settings for the selected test 

□ Override default settings 

□ Select the minimum number of healthy members for a group to report healthy 

To edit forwarding and SOCKS gateways health checks: 

1 . Select Configuration > Health Checks > General > Health Checks. 

2. Select the forwarding host test or SOCKS gateways test to modify 

3. Click Edit. 
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4. Make the necessary changes: 

a. Select the Type of Test from the drop-down list. 

b. Select the Enabled state radio button as required. 

c. Select the port setting you require. If you select Use Port, enter the new 
port number. 

d. To change the default settings for this test, click Override the default 
settings. Select the options to override. Cancel your choices by clicking 
Clear all overrides. For detailed information about configuring healthy 
and sick intervals and thresholds, see "Changing Health Check Default 
Settings" on page 357. Click OK to close the dialog. 

e. To change default notifications, click Override the default notifications. By 
default, no notifications are sent for any health checks. Select the 
options to override. You can cancel your choices by clicking Clear all 
overrides. For detailed information about configuring notifications, see 
"Configuring Health Check Notifications" on page 361. Click OK to 
close the dialog. 

f. Click OK to close the edit dialog. 

5. Click Apply. 
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To edit forwarding or SOCKS gateway group health checks: 



Note: The only way to add or delete group members to the automatically 
generated health check tests is to add and remove members from the actual 
forwarding or SOCKS gateway group. The automatically generated health 
check is then updated. 



1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the forwarding or SOCKS gateways group health check you need to 
modify. 

3. Click Edit. 




4. Make the necessary changes: 

a. Select the Enabled state radio button as required. 

b. Select the Minimum number of users that must be healthy for group to be 
healthy from the drop-down list. 

c. To create notification settings, click Override the default notifications. 

Select the options. Cancel your choices by clicking Clear all overrides. 

For detailed information about configuring notifications, see 
"Configuring Health Check Notifications" on page 361. 

d. Click OK to close the override dialog. 

e. Click OK to close the health check group. 

5. Click Apply. 

Related CLI Syntax to Edit Forwarding Groups and SOCKS Groups Health 
Checks 

The examples below use the forwarding group, fwd . group_name. 

# (config health-check) edit fwd . group_name 
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Allows you to configure options for the health check you specified. 

# (config health-check fwd . group_name) combine {all healthy | any- 
healthy | some-healthy} 

Combines the results when a group test is healthy 

# (config health-check fwd . group_name) e-mail {healthy {default | 
enable | disable} | report-all-ips {default | enable | disable} | sick 
{default I enable | disable}} 

Sends e-mail notification when the health check reports healthy or sick, 
whether or not those reports are for all IP addresses. 

# (config health-check fwd . group_name) event-log {healthy {default I 
disable | information | severe} | report-all-ips {default | enable | 
disable} | sick {default | disable | information | severe}} 

Logs an event when the health check reports healthy or sick, whether or not 
those reports are for all IP addresses. An informational or a severe event-log 
message is logged depending on the setting chosen. 

# (config health-check fwd . group_name) exit 

Exits the health check editing mode. 

# (config health-check fwd . group_name) perform-health-check 

Starts the health check immediately and reports the result. 

# (config health-check fwd .group_name) severity { critical | no-effect 
default | warning} 

Configures default severity for the health check. 

# (config health-check fwd . group_name) snmp {healthy {default | enable 
| disable} | report-all-ips {default | enable | disable} | sick {default 
| enable | disable}} 

Sends a trap when the health check reports healthy, whenever an IP address 
health check reports healthy, or when a health check reports sick. 

# (config health-check fwd .group_name) use-defaults 

Resets the defaults of the health check to use the global defaults instead of any 
explicitly set values. 

# (config health-check fwd . group_name) view {configuration | 
statistics} 

Views the health check's configuration or statistics. 

Related CLI Syntax to Edit Forwarding Hosts and SOCKS Gateway Health 
Checks 

The examples below use the forwarding host, fwd. host _name. 

# (config health-check) edit fwd. host_name 

Allows you to configure options for the health check you specified. 
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#(config health-check fwd .host^name) authentication {basic I disable | 
encrypted-password encrypted-password | password password | username 
username} 

Allows you to specify a username and password for the health-check target, if 
it uses basic authentication.(Used with HTTP or HTTPS health checks.) 

#(config health-check fwd . host_name) clear-statistics 

Clears statistics for this health check. 

# (config health-check fwd ,host_name) e-mail {healthy {default | enable 
| disable} | report-all-ips {default | enable | disable} | sick {default 
| enable | disable}} 

Sends e-mail notification when the health check reports healthy or sick, 
whether or not those reports are for all IP addresses. 

# (config health-check fwd .host_name) event-log {healthy {default | 
disable | information | severe} | report-all-ips {default | enable | 
disable} | sick {default | disable | information | severe}} 

Logs an event when the health check reports healthy or sick, whether or not 
those reports are for all IP addresses. An informational or a severe event-log 
message is logged depending on the setting chosen. 

# (config health-check fwd .host_name) exit 

Exits the health check editing mode. 

# (config health-check fwd ,host_name) failure- trigger {default | none | 
count } 

Configures options for the failure-trigger. 

# (config health-check fwd .hostname) interval {healthy {default | 
seconds} | sick {default | seconds}} 

Configures intervals before the health check is re-run. The intervals can be 
different for health checks that are reporting healthy and health checks that 
are reporting sick. 

# (config health-check fwd .hostname) perf orm-health-check 

Starts the health check immediately and reports the result. 

# (config health-check fwd .host_name) proxy-authentication {basic | 
disable | encrypted-password encrypted-password | password password | 
username username} 

Allows you to specify a username and password for the intermediate proxy. 
(Used with HTTP or HTTPS health checks, when intermediate proxies are 
between you and the target.) 

# (config health-check fwd ,host_name) response-code {add codes | remove 
codes} 

Manages a list of codes that are considered valid and result in health-check 
successes. You can add or remove codes, separated by semi-colons. If a 
success code is received by the health check, the health check considers the 
HTTP/ HTTPS test to be successful. 

(Used with HTTP or HTTPS health checks.) 
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# (config health-check fwd . hostname) severity {critical | no-effect 
default | warning} 

Configures default severity for the health check. 

# (config health-check fwd . hostname) snmp {healthy {default | enable | 
disable} | report-all-ips {default enable |disable}| sick {default | 
enable disable}} 

Sends a trap when the health check reports healthy, whenever an IP address 
health check reports healthy, or when a health check reports sick. 

# (config health-check fwd ,host_name) threshold {healthy {default | 
count } | response-time {default | none | milliseconds} | sick {default 

I count} } 

Sets the level when the health check will report healthy or sick. 

# (config health-check fwd . host_name) type (http URL \ https URL \ icmp 
hostname ! ssl hostname [port] I tcp hostname [port] } 

Sets the number of consecutive healthy or sick test results before the health 
check actually reports as healthy or sick. 

# (config health-check fwd . host_name) use-defaults 

Resets the defaults of the health check to use the global defaults instead of any 
explicitly set values. 

# (config health-check fwd . host_name) view {configuration | events 
j statistics } 

Displays the health check's configuration, recent event-log messages or 
statistics. 
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Section E: DNS Server Health Checks 

A DNS server health check is automatically generated for each DNS server 
configured on the ProxySG and is deleted when the DNS server is removed. For 
information on configuring DNS servers, refer to Volume 1: Getting Started. 

The ProxySG uses DNS server health checks to verify the responsiveness of the 
DNS server. The health check status is recorded as: 

□ Healthy, when the ProxySG successfully establishes a connection with the 
DNS server and is able to resolve the configured hostname. 

□ Unhealthy, either if the ProxySG is unable to establish a connection with the 
DNS server, or if the ProxySG is unable to resolve the configured hostname. 
The status reports Check failed or DNS failed. 

When a DNS server is unhealthy, the ProxySG avoids contacting that server and 
directs requests to other DNS servers configured in the group, as applicable. 

The DNS health check attempts to look up a configurable hostname. The default 
hostname depends on the DNS configuration: 

□ For a server in the primary or alternate DNS group, the default is 

www . bluecoat . com. 

□ For a server in a custom DNS group, the default is the longest domain name 
listed in the group. 

You can also override these defaults and specify a health check hostname for each 
DNS server. 

See Also 

DNS (Volume 1, Chapter 8) 

Editing DNS Server Health Checks 

On the ProxySG, you can edit the following settings for a DNS server health 
check: 

□ Enable or disable the health check 

□ Specify a hostname 

□ Override default settings — change healthy and sick intervals, and thresholds 

□ Override default notifications — change the severity and notification options 
for alerts 

To edit a DNS server health check: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the DNS health check to modify. 

3. Click Edit. The Edit DNS server dialog displays. 
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Health Checks Default Settings | Default Notifications 

- Health Checks 

Name i Type Test Enabled 

auth.bcjwa [Authentication [Authentication [Enabled [ 



dns. 10.2.2. 100 DNS Server DNS Server Enabled 




4. Configure the DNS server health check options: 

a. Select the Enabled state option, as required. 

• Enabled allows the ProxySG to query the DNS server and to report 
changes in the health state. 

• Disabled, reporting as healthy disables the health check and reports the 
service as healthy. 

• Disabled, reporting as sick disables the health check and reports the 
service as unhealthy. 

b. Select the Host option, as required. 

• Use default host uses the default hostname. 
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• Use user defined host allows you to configure a custom hostname for this 
health check. Enter the hostname in the box provided. 

Proceed to Step e if you do not want to override defaults. 

c. To change default settings, click Override the default settings. Select the 
options to override. Cancel your choices by clicking Clear all overrides. 

For detailed information about configuring healthy and sick intervals 
and thresholds, see "Changing Health Check Default Settings" on page 
357. Click OK to close the dialog. 

d. To change the default notifications, click Override the default notifications. 
Select the options. Cancel your choices by clicking Clear all overrides. 

For detailed information about configuring notifications, see 
"Configuring Health Check Notifications" on page 361. 

e. Click OK to close the override dialog. 

5. Click OK to close the edit dialog. 

6. Click Apply. 

Related CLI Syntax to Edit DNS Server Health Checks 

#(config health-check) edit dns . test_name 

Allows you to configure options for the health check you specified. 

#(config health-check dns . test_name) clear-statistics 

Clears statistics for this health check. 

#(config health-check dns . test^name) e-mail {healthy {default | enable 
| disable} | report-all-ips {default | enable | disable} | sick {default 
| enable | disable}} 

Sends e-mail notification when the health check reports healthy or sick, 
whether or not those reports are for all IP addresses. 

#(config health-check dns . test_name) event-log {healthy {default | 
disable | information | severe} | report-all-ips {default | enable | 
disable}| sick {default | disable | information | severe}} 

Fogs an event when the health check reports healthy or sick, whether or not 
those reports are for all IP addresses. An informational or a severe event-log 
message is logged depending on the setting chosen. 

# (config health-check dns . test_name) exit 

Exits the health check editing mode. 

# (config health-check dns . test_name) failure- trigger {default | none | 
count} 

Configures options for the failure-trigger. 

# (config health-check dns . test_name) interval {healthy {default 1 
seconds} | sick {default | seconds}} 
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Configures intervals before the health check is re-run. The intervals can be 
different for health checks that are reporting healthy and health checks that 
are reporting sick. 

#(config health-check dns . test_name) hostname {default | hostname } 

Sets the hostname for the DNS Server health check to the default hostname or 
to a user-defined hostname. 

# (config health-check dns . testname) perform-health-check 

Starts the health check immediately and reports the result. 

# (config health-check dns . test_name) severity { critical | no-effect 
default | warning} 

Configures default severity for the health check. 

# (config health-check dns . test_name) snmp {healthy {default | enable | 
disable} | report-all-ips {default | enable | disable}! sick {default | 
enable | disable}} 

Sends a trap when the health check reports healthy, whenever an IP address 
health check reports healthy, or when a health check reports sick. 

(config health-check dns . test^name) threshold {healthy {default | 
count} | response-time {default | none | milliseconds } I sick {default 

I count} } 

Sets the level when health checks will report healthy or sick. 

# (config health-check dns .test_name) use-defaults 

Resets the defaults of the health check to use the global defaults instead of any 
explicitly set values. 

# (config health-check dns . test_name) view {configuration | events 
| statistics } 

Displays the health check's configuration, recent event-log messages or 
statistics. 
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Section F: Authentication Health Checks 

This section includes information on authentication server health checks. For 
information on authentication realms, refer to Volume 4: Securing the Blue Coat 
ProxySG Appliance. 

An authentication health check is automatically generated for each external 
authentication realm that is configured on the ProxySG. Authentication health 
checks assess the realm's health based on data gathered during the most recent 
authentication attempt. The response time recorded for this health check 
represents the average response time between two consecutive health checks. 

Unlike most health checks, authentication health checks do not probe the target 
realm with an authentication request. Therefore, the health check will report 
healthy until the ProxySG records a failed authentication attempt. 

The health states for authentication health checks can be: 

□ Ok, when the ProxySG records successful authentication attempts. 

□ Check failed, when the device records an unsuccessful authentication attempt. 

□ Functioning on alternate server, when a realm is operating on its alternate server. 

□ Functioning properly with errors, when the health check records intermittent 
failures on a server. 

On an authentication health check, you can edit the following settings: 

□ Enable or disable the health check 

□ Override default settings — change healthy and sick intervals, and thresholds 

□ Override default notifications — change the severity, and notification options 
for alerts 

By default, the health check is enabled and the ProxySG tracks the response time 
for the most recent authentication attempts. The other options are — Disabled, 
reporting sick and Disabled, reporting healthy. 

Use the Disabled, reporting sick option when an authentication server requires 
downtime for maintenance, or the server is taken off-line temporarily. And the 
Disabled, reporting healthy option is relevant when you elect to use an 
authentication server despite failures in authentication attempts. 

To edit an authentication health check: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the auth. test _name health check to modify. 

3. Click Edit. The Edit Authentication health check dialog displays 
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Health Checks Default Settings | Default Notifications 

- Health Checks 

Name i Type Test Enabled 



auth.bcjwa Authentication Authentication Enabled 




4. Configure the authentication health check options: 

a. Select the Enabled state radio button as required. 

b. To change the default settings, click Override the default settings. Select 
the options to override. Cancel your choices by clicking Clear all 
overrides. For detailed information about configuring healthy and sick 
intervals and thresholds, see "Changing Health Check Default 
Settings" on page 357. Click OK to close the dialog. 

c. To change the default notifications, click Override the default notifications. 
Select the options. Cancel your choices by clicking Clear all overrides. 
For detailed information about configuring notifications, see 
"Configuring Health Check Notifications" on page 361. Click OK to 
close the dialog. 

d. Click OK to close edit dialog. 

5. Click Apply. 

Related CLI Syntax to Edit Authentication Health Checks 

#(config health-check) edit auth . test^name 

Allows you to configure options for the health check you specified. 

#(config health-check auth . test_name) clear-statistics 

Clears statistics for this health check. 
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#(config health-check auth . test^name) e-mail {healthy {default | 
enable | disable}! report-all-ips {default I enable | disable}! sick 
{default | enable | disable}} 

Sends e-mail notification when the health check reports healthy or sick, 
whether or not those reports are for all IP addresses. 

#(config health-check auth . test_name) event-log {healthy {default | 
disable | information | severe} | report-all-ips {default | enable | 
disable}! sick {default | disable | information | severe}} 

Logs an event when the health check reports healthy or sick, whether or not 
those reports are for all IP addresses. An informational or a severe event-log 
message is logged depending on the setting chosen. 

# (config health-check auth . test_name) exit 

Exits the health check editing mode. 

# (config health-check auth . test_name) failure-trigger {default | none 
I count} 

Configures options for the failure-trigger. 

# (config health-check auth . test_name) interval {healthy {default | 
seconds} | sick {default | seconds}} 

Configures intervals before the health check is re-run. The intervals can be 
different for health checks that are reporting healthy and health checks that 
are reporting sick. 

# (config health-check auth . test_name) perform-health-check 

Starts the health check immediately and reports the result. 

# (config health-check auth . test^name) severity { critical | no-effect 
default | warning} 

Configures default severity for the health check. 

# (config health-check auth . test_name) snmp {healthy {default I enable 
| disable}! report-all-ips {default | enable | disable}! sick {default 
| enable | disable}} 

Sends a trap when the health check reports healthy, whenever an IP address 
health check reports healthy, or when a health check reports sick. 

# (config health-check auth ,host_name) threshold {healthy {default | 
count } | response-time {default | none | milliseconds} | sick {default 

I count} } 

Sets the level when health checks will report healthy or sick. 

# (config health-check auth . test_name) use-defaults 

Resets the defaults of the health check to use the global defaults instead of any 
explicitly set values. 

# (config health-check auth . test_name) view {configuration | events 
| statistics } 

Displays the health check's configuration, recent event-log messages or 
statistics. 
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Section G: Virus Scanning and Content Filtering Health Checks 

The virus scanning and content filtering services include ICAP services, Websense 
off-box services, and the DRTR service. While these external service health checks 
are created and deleted automatically, the service itself must be created before 
health checks can be used. For more information about creating ICAP and 
Websense off-box services, refer to Volume 7: Managing Content. The DRTR service 
health check is automatically created if you use Blue Coat Web Filter (BCWF) and 
the rating service is enabled. 

The health check system conducts external service tests by sending requests to the 
external services system, which reports back a health check result.The tests for 
each of the external services is specialized and is devised specifically for each 
service. 



Note: The names of the ICAP and Websense off-box services and service groups 
can be a maximum of 64 characters long, a change from previous releases, which 
allowed names to be a maximum of 127 characters. If a previously existing name 
exceeds 64 characters, the service or service group continues to function normally 
but no corresponding health check type is created. 



The settings you can change on ICAP, Websense off-box, and DRTR service health 
checks are: 

□ Enable or disable the health check 

□ Override default settings 

□ Override default notifications 

To edit virus scanning and content filtering tests: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the external service to modify. External services have prefix names of 

drtr, icap, and ws. 

3. Click Edit. 
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a. Select the Enabled state radio button as required. 

b. (Websense only): If you do not want to use the default URL, select the 
Use user defined URL option and enter the test URL to use. 

c. To change default settings, click Override the default settings. 

• Select the check boxes to override. Cancel your choices by clicking 
Clear all overrides. For detailed information about configuring healthy 
and sick intervals and thresholds, see "Changing Health Check Default 
Settings" on page 357. 



Note: DRTR health check has default settings that differ from the 
defaults for other external services: 10800 seconds (3 hours) for the 
interval, and 1 for the failure trigger. 



• Click OK. 

d. To change default notifications, click Override the default notifications. By 
default, no notifications are sent for any health checks. Select the 
options. Cancel your choices by clicking Clear all overrides. For detailed 
information about configuring notifications, see "Configuring Health 
Check Notifications" on page 361. 

e. Click OK to close the override dialog. 

f. Click OK to close the edit dialog. 

5. Click Apply. 
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Related CLI Syntax to Modify ICAP Service and Content Filtering Health 
Checks 

The examples below use Blue Coat's Content Filter — DRTR_ 

#(config health-check) edit drtr . test_name 

Allows you to configure options for the health check you specified. 

#(config health-check drtr . test_name) clear-statistics 

Clears statistics for this health check. 

#(config health-check drtr . test_name) e-mail {healthy {default | 
enable | disable} | report-all-ips {default | enable |disable}| sick 
{default | enable | disable}} 

Sends e-mail notification when the health check reports healthy or sick, 
whether or not those reports are for all IP addresses. 

#(config health-check drtr . test_name) event-log {healthy {default | 
disable | information | severe} | report-all-ips {default | enable | 
disable} | sick {default disable ] inf ormation | severe}} 

Logs an event when the health check reports healthy or sick, whether or not 
those reports are for all IP addresses. An informational or a severe event-log 
message is logged depending on the setting chosen. 

# (config health-check drtr . test^name) exit 

Exits the health check editing mode. 

# (config health-check drtr . test_name) failure-trigger {default none | 
count } 

Configures options for the failure-trigger. 

# (config health-check drtr . test_name) interval {healthy {default | 
seconds} | sick {default | seconds} } 

Configures intervals before the health check is re-run. The intervals can be 
different for health checks that are reporting healthy and health checks that 
are reporting sick. 

# (config health-check drtr . test^name) perform-health-check 

Starts the health check immediately and reports the result. 

# (config health-check drtr . test_name) severity { critical | no- 
effect I default | warning } 

Configures default severity for the health check. 

# (config health-check drtr . test_name) snmp {healthy {default | enable 
| disable} | report-all-ips {default | enable | disable} | sick {default 
| enable | disable}} 

Sends a trap when the health check reports healthy, whenever an IP address 
health check reports healthy, or when a health check reports sick. 

# (config health-check drtr . test_name) threshold {healthy {default 
I count] | response-time {default | none] milliseconds } | sick {default 

I count} } 
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Sets the level when the health check will report healthy or sick. 

#(config health-check ws . test_name) test-url {default |url} 

(Used only with the WebSense health checks) Sets the test URL to default. 

#(config health-check dr tr . test_name) use-defaults 

Resets the defaults of the health check to use the global defaults instead of any 
explicitly set values. 

# (config health-check dr tr . test_name) view {configuration | events 
| statistics } 

Displays the health check's configuration, recent event-log messages or 
statistics. 

To edit Websense off-box or ICAP group tests: 

Note: The only way to add or delete group members to the automatically 
generated health check tests is to add and remove members from the ICAP or 
Websense off-box services. The automatically generated health check type is 
then updated. 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the external service group health check to modify. Groups are identified 
in the Type column. 

3. Click Edit. 
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4. Make the necessary changes: 

a. Enable or disable the Enabled state radio button as required. 

b. Select the Minimum number of members that must be healthy for group to be 
healthy from the drop-down list. The default is set to one. 

c. To create notification settings, click Override the default notifications. 

Select the options. Cancel your choices by clicking Clear all overrides. 

For detailed information about configuring notifications, see 
"Configuring Health Check Notifications" on page 361. 

d. Click OK to close the override dialog. 

e. Click OK to close the edit dialog. 

5. Click Apply. 

Related CLI Syntax to Modify ICAP and Websense Group Tests 

The examples below use Websense. 

# (config health-check) edit ws . groupname 

Allows you to configure options for the health check you specified. 

# (config health-check ws . group_name) combine {all healthy | any- 
healthy | some-healthy} 

Combines the results when a group test is healthy. 

# (config health-check ws .group_name) e-mail {healthy {default | enable 
| disable} | report-all-ips {default | enable | disable} | sick {default 
| enable | disable}} 

Sends e-mail notification when the health check reports healthy or sick, 
whether or not those reports are for all IP addresses. 

# (config health-check ws .group_name) event-log {healthy {default | 
disable j information | severe} | report-all-ips {default enable | 
disable}! sick {default | disable | inf ormation 1 severe}} 
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Logs an event when the health check reports healthy or sick, whether or not 
those reports are for all IP addresses. An informational or a severe event-log 
message is logged depending on the setting chosen. 

# (config health-check ws . group_name) exit 

Exits the health check editing mode. 

# (config health-check ws . group_name) perf orm-health-check 

Starts the health check immediately and reports the result. 

# (config health-check ws ,group_name) snmp {healthy {default | enable | 
disable} | report-all-ips {default | enable | disable}! sick {default | 
enable disable}} 

Sends a trap when the health check reports healthy, whenever an IP address 
health check reports healthy, or when a health check reports sick. 

# (config health-check ws .group_name) use-defaults 

Resets the defaults of the health check to use the global defaults instead of any 
explicitly set values. 

# (config health-check ws . group_name) view {configuration events 
| statistics } 

Displays the health check's configuration, recent event-log messages or 
statistics. 
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Section H: Managing User-Defined Health Checks 

You can manually create and manage ICMP, TCP, HTTP, HTTPS, or SSL health 
check tests for any upstream TCP/IP device. You can use these user-defined 
health check types to send notifications of health check state changes. 

Under most circumstances, you do not need to create user-defined health checks 
because the automatically generated health checks meet most needs. However, to 
check for things that Blue Coat does not test for automatically — for example, the 
health of the Internet or of the router, you might create user-defined heath checks. 

If, for example, you want to control Web traffic based on the apparent health of 
the Internet, you can create a user-defined health check to target known Internet 
sites. As long as a certain number of the sites are healthy, you can consider the 
Internet as healthy. 

Further, you can use policy to configure forwarding rules on the ProxySG. 
Subsequently, if the user-defined health check determining internet accessibility 
transitions to unhealthy, all requests directed to the ProxySG will be forwarded to 
the alternate ProxySG until the primary ProxySG transitions to healthy again. 



Note: Frequent testing of specific Internet sites can result in that Internet site 
objecting to the number of hits. 



Blue Coat supports two types of user-defined health checks: 

□ Host: This health check type is for any upstream TCP/IP device. For more 
information, continue with the next section. 

□ Composite: This health check type combines the results of other existing 
health checks. It can include other composite health checks, health checks for 
user defined hosts, and any automatically generated health checks. For more 
information, continue with "About User-Defined Composite Health Checks" 
on page 387. 

For information about configuring parameter and notification settings for 
automatically generated health check types, see Section C: "Configuring Global 
Defaults" on page 355. 

About User-Defined Host Health Checks 

You can create, configure, and delete user-defined host health checks. These 
health checks support everything an automatically generated health check 
contains, including background DNS resolution monitoring and support for 
multiple addresses. 

User-defined health checks can include: 

□ ICMP: The basic connection between the ProxySG and the origin server is 
confirmed. The server must recognize ICMP echoing, and any intervening 
networking equipment must support ICMP. 
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□ TCP: Establishes that a TCP layer connection can be made to a port on the 
host. Then the connection is dropped. 

□ SSL: A connection is made to a target and the full SSL handshake is confirmed. 
Then the connection is dropped. 

□ HTTP/HTTPS: An HTTP or HTTPS test is defined by the URL supplied. The 
port used for this test is as specified in that URL. If no port is explicitly 
specified in the URL, the port defaults to the standard Internet value of 80 or 
443. 

When configuring user-defined host health check types, keep the following in 

mind: 

□ User-defined host health checks are created and deleted manually. 

□ All individual user-defined tests consider the target to be a server. 

□ To conduct proxy HTTP/HTTPS tests, a proxy must be defined as a 
forwarding host, set up between the originating device and the target, and 
forwarding policy must cause the test to be directed through the proxy. 

□ Lor an ICMP test, a hostname is specified in the health check configuration. 

□ The TCP and SSL tests support SOCKS gateway policy, based on a URL of 

tcp: // hostname: port/ and ssl : / / hostname-.port/ , respectively, using a 
hostname and port supplied in health check configuration. 

□ An HTTP/HTTPS test requires a full URL. The port used for this test is as 
specified in that URL. If no port is explicitly specified in the URL, the port 
defaults to the standard value for these protocols of 80 or 443. The server 
being tested is assumed to support whatever port is indicated. 

Lorwarding and SOCKS gateway policy is applied based on the URL. The 
HTTPS or SSL tests use all the server certificate settings in the SSL layer in 
policy. Lor a forwarding host, all the sever certificate settings in the SSL layer 
also apply, and if present, override the forwarding host configuration setting. 



Note: None of the above tests apply to user-defined composite health checks, 
which only consist of a set of members and a setting to combine the results. 



About User-Defined Composite Health Checks 

You can create a composite health check to combine the results of multiple health 
checks. A composite health check can contain any number of individual health 
checks. Lurther, forwarding host and SOCKS gateway health checks can be 
configured to use the result of a composite health check. 

By default, to report healthy, all members of a composite health check must be 
healthy. However, you can configure the number of members that must be 
healthy for the composite result to report healthy. 

Composite health checks with no members always appear unhealthy. 
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Note: Automatically generated group tests and user-defined composite tests 
are not the same. 

Group tests are automatically generated; they cannot be deleted. Some 
editing is permitted, but you cannot add or remove members of the group 
through the health checks module. You must modify the forwarding or 
SOCKS gateways groups to update the automatically generated group tests. 

For a group test, the default is for the group to be healthy if any member is 
healthy. For a composite test, the default is for the group to be healthy if all 
members are healthy. (The default is configurable.) 



Creating User-Defined Host and Composite Health Checks 

You can create user-defined host and composite health checks for arbitrary 
targets. 



Note: You cannot create user-defined health checks for external service tests, 
such as authentication servers, ICAP, Websense off-box, and the DRTR 
service. 



The following procedure explains how to create a user-defined host health check. 
To create a user-defined composite health check, continue with "To create a user- 
defined composite health check:" on page 392. 

To create a user-defined host health check: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Click New. 
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User Defined Host Health Check 



- User Defined Host Health Check 

Name: 



HTTPS 



Enabled state: 0 Enabled 

o Disabled, reporting as healthy 
0 Disabled, reporting as sick 

URL: https:// 

- Authentication 

I"! Enable basic authentication 
Username: 

- Proxy Authentication 

n Enable basic proxy authentication 
Username: 

- Allowed Response Codes 

Allowed Response Codes: 

- Override Defaults 

| override ] the default settings 

| override I ^e default notifications 



OK ] ( Cancel ] 

3. Select the type of test to configure from the Type of test drop-down list. To 
configure a composite test, see "To create a user-defined composite health 
check:" on page 392. 

The options you can select vary with the type of health check. The example 
above uses the HTTP /HTTPS options. Options for other tests are explained in 
this procedure, as well. 

a. Enter a name for the health check. 

b. Select the Enabled state option, as required. 

c. If you are configuring an SSL or TCP health check, enter the port to 
use. 

d. If you are configuring an ICMP, SSL, or TCP health check, enter the 
hostname of the health check's target. 

e. For HTTP/HTTPS only: 

• Enter the URL address of the target. 
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• To use Basic user authentication, select the check box and enter the 
username and password of the target. 

• To use Basic proxy authentication because intermediate proxies might 
be between you and the target, select the check box and enter the 
username and password of the target. 

• To manage a list of HTTP /HTTPS response codes that are considered 
successes, enter the list in the Allowed Response Code field, separated by 
semi-colons. If one of them is received by the health check then the 
health check considers the HTTP(S) test to have been successful. 



Note: The 200 response code is added by default. The list must always 
have at least one member. 



f. To change the default settings for this test, click Override the default 
settings. Select the override options. Cancel your choices by clicking 
Clear all overrides. For detailed information about configuring healthy 
and sick intervals and thresholds, see "Changing Health Check Default 
Settings" on page 357. Click OK. 

g. To change the default notifications for this test, click Override the default 
notifications. By default, no notifications are sent for any health checks. 
Select the override options. You can cancel your choices by clicking 
Clear all overrides. For detailed information about configuring 
notifications, see "Configuring Health Check Notifications" on page 
361 Click OK. 

h. Click OK to close the dialog. 

4. Click Apply. 

Related CLI Syntax to Create and Modify User-Defined Host Health 
Checks 

#(config health-check) create {composite alias_name | http alias_name 
url | https alias_name url | icmp alias_name hostname I ssl alias_name 
hostname [port] I tcp alias^name hostname [port]} 

Creates a user-defined health check of the type specified. 

# (config health-check) edit health_check_name 

Allows you to configure options for the health check you specified. 

# (config health-check user . heal th^check^name) authentication {basic | 
disable | encrypted-password encrypted-password | password password | 
username username } 

Allows you to specify a username and password for the health-check target, if 
its allows basic authentication. (Used with HTTP or HTTPS health checks.) 

# (config health-check user . heal th^check^name) clear-statistics 

Clears statistics for this health check. 
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# (config health-check user . heal th_check_name) e-mail {healthy {default 
| enable | disable}! report-all-ips {default | enable | disable}! sick 
{default | enable | disable}} 

Sends e-mail notification when the health check reports healthy or sick, 
whether or not those reports are for all IP addresses. 

# (config health-check user . heal th_check_name) event-log {healthy 
{default | disable | information | severe} | report-all-ips {default | 
enable | disable}! sick {default | disable | information | severe}} 

Logs an event when the health check reports healthy or sick, whether or not 
those reports are for all IP addresses. An informational or a severe event-log 
message is logged depending on the setting chosen. 

# (config health-check user . heal th_check_name) exit 

Exits the health check editing mode. 

# (config health-check user . heal th_check_name) failure- trigger {default 
| none | count} 

Configures options for the failure-trigger. 

# (config health-check user . heal th_check_name) interval {healthy 
{default | seconds} | sick {default | seconds}} 

Configures intervals before the health check is re-run. The intervals can be 
different for health checks that are reporting healthy and health checks that 
are reporting sick. 

# (config health-check user . heal th_check_name) perf orm-health-check 

Starts the health check immediately and reports the result. 

# (config health-check user . heal th_check_name) proxy-authentication 
{basic I disable | encrypted-password encrypted-password | password 

password I username username} 

Allows you to specify a username and password for the intermediate proxy. 
(Used with HTTP or HTTPS health checks, when intermediate proxies are 
between you and the target.) 

# (config health-check user . heal th^check_name) response-code {add codes 
| remove codes} 

Manages a list of codes that are considered valid and result in health-check 
successes. You can add or remove codes, separated by semi-colons. If a 
success code is received by the health check, the health check considers the 
HTTP/ HTTPS test to be successful. (Used with HTTP or HTTPS health 
checks.) 

# (config health-check user . heal th_check_name) severity {critical | no- 
effect | default I warning} 

Configures default severity for the health check. 

# (config health-check user . heal th_check_name) snmp {healthy {default I 
enable | disable}! report-all-ips {default | enable |disable}| sick 
{default | enable disable}} 

Sends a trap when the health check reports healthy, whenever an IP address 
health check reports healthy, or when a health check reports sick. 
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# (config health-check user . heal th^check_name) threshold {healthy 
{default | count } | response-time {default | none | milliseconds} | 

sick {default | count} } 

Sets the threshold level when the health check will report healthy or sick. 

# (config health-check user . heal th^check^name) type (http URL | https 
URL | icmp hostname | ssl hostname [port] | tcp hostname [port] } 

Sets the number of consecutive healthy or sick test results before the health 
check actually reports as healthy or sick. 

# (config health-check user . heal th^check_name) use-defaults 

Resets the defaults of the health check to use the global defaults instead of any 
explicitly set values. 

# (config health-check user . heal th^check_name) view {configuration | 
events | statistics} 

Displays the health check's configuration, recent event-log messages or 
statistics. 

To create a user-defined composite health check: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Click New. 
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3. Make the necessary changes: 

a. Select Composite from the Type of Test from the drop-down list. 

b. Enable or disable the Enabled state option as required. 

c. Select the Minimum number of members that must be healthy for the group to 
be healthy from the drop-down list. The default is All. 

d. Add the health check members to the composite test from the Available 
Aliases list by selecting the health check to add and clicking Add to 
move the alias to the Selected Alias list. 

e. To change the default notifications for this test, click Override the default 
notifications. By default, no notifications are sent for any health checks. 
Select the override options. You can cancel your choices by clicking 
Clear all overrides. For detailed information about configuring 
notifications, see "Configuring Health Check Notifications" on page 
361 

f. Click OK to close the override dialog. 

g. Click OK to close the edit dialog. 

4. Click Apply. 
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Related CLI Syntax to Create and Modify User-Defined Composite Health 
Checks 

#(config health-check) create {composite alias_name | http alias_name 
url | https alias_name url | icmp alias_name hostname | ssl alias_name 
hostname [port]] tcp alias^name hostname [port]] 

Creates a user-defined health check of the type specified. 

# (config health-check) edit composite_health__check 

Edits the specified composite health check. 

# (config health-check user . composi te_heal th_check) add member_name 

Adds the specified member to the composite health check group. 

# (config health-check user . composi te_heal th_check) combine {all- 
healthy | any-healthy | some-healthy} 

Requires that all, some, or any members of the group report as healthy to have 
the composite health check report as healthy. 

# (config health-check user . composi te_heal th_check) e-mail {healthy 
{default | enable |disable}| report-all-ips {default enable |disable}| 
sick {default | enable Idisable}} 

Sends e-mail notification when the health check reports healthy or sick, 
whether or not those reports are for all IP addresses. 

# (config health-check user . composi te_heal th_check) event-log {healthy 
{default Idisable | inf ormation j severe} | report-all-ips {default 
enable | disable} | sick {default Idisable | inf ormation | severe}} 

Logs an event when the health check reports healthy or sick, whether or not 
those reports are for all IP addresses. An informational or a severe event-log 
message is logged depending on the setting chosen. 

# (config health-check user . composi te_heal th_check) exit 

Exits the composite health check editing submode. 

# (config health-check user . composi te_heal th_check) perform-health- 
check 

Performs a health check on the members of the composite immediately and 
reports the result. 

# (config health-check user . composi te_heal th_check) remove member_name 

Removes a member from the composite group. 

# (config health-check user . composi te_heal th check) snmp {healthy 
{default | enable | disable} | report-all-ips {default | enable | disable) | 
sick {default | enable | disable)) 

Sends a trap when the health check reports healthy or sick, whether or not 
those reports are for all IP addresses. 

# (config health-check user . composi te_heal th_check) severity {critical 
| default | no-effect | warning} 
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Sets the severity level of the health check, which determines how this health 
check affects the overall health of the device. 

#(config health-check user . compos ite_health_check) use-defaults 

Resets the defaults of the health check to use the global defaults instead of any 
explicitly set values. 

# (config health-check user . compos ite_health_check) view {configuration 
events | statistics } 

Displays the composite health check's configuration, event log messages, or 
statistics. 

Copying and Deleting User-Defined Health Checks 

Only user-defined health checks can be copied and deleted. Automatically 
generated health checks cannot be copied or deleted. 

□ If the source health check is user-defined host or a composite and the target 
alias name does not exist: 

• A new health check of the same kind with that alias name is created 

• The new health check has identical configuration settings to the source 
health check. 

□ If the target alias does exist and the target is of the same kind (that is, both are 
user- defined hosts or both are composite), then the complete configuration is 
copied from the source to the target. 

□ If a health check is referenced either in policy or in another health check, it 
cannot be deleted. 

To copy or delete a user-defined host or composite health check: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the user-defined host or composite health check to copy or to delete. 

3. Click Copy or Delete, as applicable. 




If the target does not match the source type, the copy operation fails and you 
receive an error message. 

Related CLI Syntax to Copy and to Delete a User-Defined Health Check 

# (config health-check) copy source-alias target-alias 
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Copies settings from one health check to another, creating the target if 
necessary. 

#(config health-check) delete alias_name 

• Deletes the specified health check. 
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Section I: Viewing Health Check Statistics 

The ProxySG presents a comprehensive list of all the health checks configured on 
the appliance in the Statistics > Health Checks tab. You can view the details and 
events for each health check in this screen, to edit the health checks, go to the 

Configuration > Health Checks > General tab. 

To view health checks on the ProxySG: 

Select Statistics > Health Checks. The list of configured health checks displays. 




Health Checks 

Current Time: 2008-01-23 11:17:16 LastBoot: 2008-01-2211:35:08 SinceBoot: 23.7hrs 



Status 


Last check 




Since last transition 






Name * 


State 


When 


Time (ms) 


Duration 


#Checks 


Avg (ms) 


Min (ms) 


Max (ms) 


auth.bcjwa 


3 on alt server 


11:17:12 


6 


17.0 min 


20 


8 


5 


11 


auth.blue_coat_ldap 


Unknown 
















dns. 10.2.2. 100 


OK with errors 


11:17:01 


4 


23.7 hrs 


5,537,695 


5 


3 


40 


dns. 10.2.2. 101 


Check failed 


11:17:08 


3 


18.0 min 


46 








dns.172. 16.90. 110 


Q ok 


11:17:09 


15 


23.7 hrs 


3,892,344,090 


18 


13 


459 


socks, gateway 1 


Qok 


11:16:49 


12 


3.7 hrs 


2,837 


65 


18 


1,614 


drtr.rating_service 


(2) OK for some IPs 


08:41:57 


5,104 


17.6 hrs 


8,544 


5,568 


96 


10,071 


fwd. google 


Qok 


11:17:00 


28 


20.2 hrs 


10,790 


47 


28 


3,072 


fwd.my_ssh 


Qok 


11:17:14 


5 


23.7 hrs 


2,810 


6 


4 


75 


icap. inbound 


Qok 


11:17:13 


18 


38.6 min 


82 


22 


17 


286 


icap. outbound 


Qok 


11:17:11 


17 


36.6 min 


77 


18 


16 


26 


icap. test 


Q Disabled: Healthy 


1995-12-31 


9,990 


23.7 hrs 


4,258 


9,992 


9,970 


10,032 


socks, personal 


Q| Disabled: Unhealthy 


11:15:08 


994 


18.6 min 


91 








user, group 


1 Check failed 


1995-12-31 


546 


23.7 hrs 


10,872 








user . public . dns . server 


Qok 


11:17:15 


21 


23.7 hrs 


3,330,935,572 


53 


15 


1,194 



| Details | | Events | 



About Health Check Statistics 

The Statistics > Health Check panel provides a snapshot of all the health checks 
configured on the device. By default, the screen is sorted by the name column. To 
change the sort order, click any column header to sort by that column. 

The Statistics > Health Check screen displays the following information: 

□ Current time: Displays the current date and time. 

□ Last Boot: Displays the date and time when the device was last booted. 

□ Since Boot: Displays the time that the device has been functioning since the last 
boot. 

□ Status: Displays the summary of each health check configured on the ProxySG. 

• Name: The health check name. Example, auth.blue_coat_iwa 

• State: The health check state is represented by an icon and a status 
message. If the health check is disabled, it displays as: 

• Disabled: Healthy 
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• Disabled: Unhealthy 

If the health check is enabled, the table below shows the messages 
displayed: 



Table 14-2 Status messages for enabled health checks 



Status Message 


Icon 


Description 


Health State 


Unknown 


o 


Health has not yet been tested 
successfully. 


Healthy 


OK 


o 


The target device or service is 
completely healthy. 


Healthy 


OK with errors (multiple 
IP addresses) 


O 


One or more IP addresses have 
errors but none are down. 


Healthy 


OK for some IP 
addresses (multiple IP 
addresses) 


o 


One or more IP addresses are 
down but not all. 


Healthy 


OK on alt server 


Q 


The primary server has failed; the 
realm is functioning on the 
alternate server. 


Healthy 


Functioning but going 
down (single IP address) 


O 


Failures are occurring; but the IP 
address is still functioning. 


Healthy 


Check failed 


o 


Device or service cannot be used. 


Unhealthy 


DNS failed 


o 


The hostname cannot be resolved 


Unhealthy 



□ Last check: Information on the last completed health check probe. 

• When: Time of the last check. 

• Time: Response time of the last check. 

□ Since last transition: Displays aggregate values since the last transition between 

healthy and unhealthy. 

• Duration: Length of time since the last transition. 

• #Checks: Number of health checks performed since the last transition. 

• Avg: The mean response time since the last transition. This statistic is not 
displayed for a health check reporting unhealthy. 

• Min: Minimum response time. This statistic is not displayed for a health 
check reporting unhealthy. 

• Max: Maximum response time. This statistic is not displayed for a health 
check reporting unhealthy. 
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□ Details: This option is active only if a single row is selected. When you click 
Details, it displays a new HTML window that contains detailed statistics on the 
selected health check. For example, in a domain check, this display provides 
an itemized explanation about each IP address in a domain. 

□ Events: This button is active only when a single row is selected. When you 
click the button, it displays a new HTML window containing the filtered 
event log entries for the selected health check. 



399 



Volume 5: Advanced Netzvorking 



Section I: Viewing Health Check Statistics 

Interpreting Health Check Statistics 

The Statistics > Health Check tab in the Management Console provides a snapshot of 
all the health checks configured on the ProxySG. This screen allows you to glance 
at the health checks for routine maintenance, to diagnose potential problems, and 
to view health check failures. 

The screenshot below shows the Statistics > Health Check panel along with an 
explanation of the display 




□ The current time is 11:17 on January 23, 2008 

□ Authentication realm Blue Coat IWA — auth.bc_iwa is functioning on its 
alternate server for 17 minutes. The primary server failed just 17 minutes ago. 

□ Authentication realm Blue Coat LDAP — auth.blue_coat_ldap is configured, 
but is not currently referenced in policy. The health state is Unknown because it 
is not being queried by the ProxySG for authentication lookups or for health 
checks. 

□ DNS server — dns.10.2.2.100 is functioning with errors, and it reports healthy 
since boot. Select the row and click Events to view the expanded display about 
the earlier failed health check. 

□ DNS server — dns.10.2.2.101 is not functioning since 11:17 (for 18 minutes 
now). Select the row and click Details to view the expanded display for the 
health check. 

□ DNS server 172.16.90.110 reports healthy and is stable since the device was 
booted. 
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□ SOCKS gateway — socks.gatewayl is healthy and is operating for the last 3.7 
hours. The average response time for this gateway is 65 ms. 

□ DRTR service group — dr tr. rating-service is healthy, and the average response 
time is adequate. However the status icon shows that the service is 
experiencing difficulties with some IP addresses. Select the row and click 
Details to view the information on the configured IP addresses and the failure 
points. The Details button displays the following information: 

Domain name: sp.cwfservice.net DNS status: success 
Enabled OK for some IPs UP 

IP address: 217.169.46.101 Enabled OK UP 

Last status: Success. 

Successes (total): 8 (last): Wed, 23 Jan 2008 16:35:36 GMT 
(consecutive) : 8 

Failures (total): 0 (last): Never (consecutive): 0 (external): 0 
Last response time: 331 ms Average response time: 357 ms 
Minimum response time: 300 ms Maximum response time: 613 ms 
IP address: 65.160.238.181 Enabled Check failed DOWN 
Last status: A communication error has occurred. 

Successes (total): 0 (last): Never (consecutive): 0 

Failures (total): 3809 (last): Wed, 23 Jan 2008 16:45:09 GMT 
(consecutive) : 3809 (external) : 0 

Last response time: 9990 ms Average response time: 9992 ms 
Minimum response time: 9981 ms Maximum response time: 10071 ms 
IP address: 204.246.129.201 Enabled OK UP 
Last status: Success. 

Successes (total): 8 (last): Wed, 23 Jan 2008 16:41:57 GMT 
(consecutive) : 6 

Failures (total) : 15 (last) : Wed, 23 Jan 2008 01:41:44 GMT 
(consecutive) : 0 (external) : 0 

Last response time: 104 ms Average response time: 1133 ms 
Minimum response time: 96 ms Maximum response time: 6281 ms 
IP address: 65.160.238.183 Enabled Check failed DOWN 

Last status: A communication error has occurred. 

Successes (total) : 0 (last) : Never (consecutive) : 0 
Failures (total): 3809 (last): Wed, 23 Jan 2008 16:45:09 GMT 
(consecutive) : 3809 (external) : 0 

Last response time: 9991 ms Average response time: 9993 ms 
Minimum response time: 9981 ms Maximum response time: 10067 ms 

□ Forwarding host — fwd. google is functioning for 20.2 hours. 

□ The forwarding host — fwd.my ssh is healthy since boot. 

□ ICAP service — icap . inbound and icap . outbound are healthy. 

□ ICAP service — icap . test is disabled and configured to report healthy. 
Disabled health checks appear grayed out on the screen. 

□ SOCKS gateway — socks . personal is disabled and configured to report 
unhealthy. 



401 



Volume 5: Advanced Netzvorking 



Section I: Viewing Health Check Statistics 

□ The user-defined health check — user . public . dns . server is healthy. 
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The results of a health check can be affected through forwarding, SOCKS gateway, 
or SSL certificate policy. The health check transactions execute the <forward> layer 
and (for SSL or HTTPS tests) the <ssi> layer to determine applicable policy 

This allows health check behavior to match as closely as possible to that of the SSL 
traffic that the health check is monitoring. 

Health checks cannot be deleted while referenced in policy. If a health check is 
automatically deleted when its target is deleted, a reference to the health check in 
policy can block deletion not only of the health check but of its target. 

Two policy conditions exist for health checks: 

□ health _check= : This condition tests whether the current transaction is a health 
check transaction. Optionally, the condition tests whether the transaction is 
that of a specific health check. 

□ is_heaithy ,heaith_check_name= : This condition tests whether the specified 
health check is healthy. 

Example: For a user-defined health check user .internet that gates access to a 
popular Website and tests for Internet connectivity and responsiveness, you could 
define policy to redirect traffic through a forwarding host if the health check fails. 

To do this in policy: 

<Forward> 

is_healthy. user . internet = no forward (alternate_route) 

For more information about using policy, refer to Volume 6: The Visual Policy 
Manager and Advanced Policy and Volume 10: Content Policy Language Guide. 
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Section K: Related CLI Syntax to Configure Health Checks 

□ To enter health check mode: 

SGOS# (config) health-check 
SGOS# (config health-check) 



Note: For detailed information about using these commands, refer to Volume 
11: Command Line Interface Reference. 



□ The following subcommands are available: 



SGOS# (config health-check) copy source-alias target-alias 
SGOS# (config health-check) create {composite alias_name I http 
alias_name url | https alias_name url | icmp alias_name hostname | ssl 
alias_name hostname [port] | tcp alias_name hostname [port]} 

SGOS# (config health-check) default e-mail {healthy {enable Idisable} | 
report-all-ips {enable Idisable} | sick {enable Idisable}} 

SGOS# (config health-check) default event-log {healthy { disable 
| information | severe} | report-all-ips {enable Idisable} | sick {enable 
disable} } 

SGOS# (config health-check) default failure- trigger {none | count} 

SGOS# (config health-check) default interval {healthy seconds | sick 
seconds} 



SGOS# (config health-check) default snmp {healthy {enable Idisable} | 
report-all-ips {enable Idisable} | sick {enable Idisable}} 

SGOS# (config health-check) default severity {no-effect | warning 
| critical } 



SGOS# (config health-check) default threshold {healthy count \ 
response-time milliseconds I sick count } 

SGOS# (config health-check) delete alias_name 

SGOS# (config health-check) disable {healthy alias_name | sick 
alias name } 



SGOS# (config health-check) 
(config health-check heal 



SGOS# (config 
SGOS# (config 
SGOS# (config 

SGOS# (config 

statistics } 



health-check) 
health-check) 
health- check) 
health- check) 



edit health_check_name 
th_check_name) subcommands 
enable alias_name 

exit 

perf orm-health-check alias_name 
view {configuration | quick-statistics 
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This chapter describes the TCP/IP configuration options, which enhance the 

performance and security of the ProxySG. Except for IP Forwarding (refer to 

Volume 2: Proxies and Proxy Services), these commands are only available 

through the CLI. 

Topics in this Chapter 

The following topics are discussed in this chapter: 

□ "About the Options" on page 405 

□ "RFC-1323" on page 406 

□ "TCP NewReno" on page 406 

□ "ICMP Broadcast Echo Support" on page 406 

□ "ICMP Timestamp Echo Support" on page 406 

□ "TCP Window Size" on page 407 

□ "PMTU Discovery" on page 407 

□ "TCP Time Wait" on page 408 

□ "TCP Loss Recovery Mode" on page 408 

□ "TCP Loss Recovery Mode" on page 408 

About the Options 

□ RFC-1323: Enabling RFC-1323 support enhances the high-bandwidth and 
long-delay operation of the ProxySG appliances over very high-speed 
paths, ideal for satellite environments. 

□ TCP NewReno: Enabling TCP NewReno support improves the fast 
recovery of the appliances. 

□ ICMP Broadcast Echo: Disabling the response to these messages can limit 
security risks and prevent an attacker from creating a distributed denial of 
service (DDoS) to legitimate traffic. 

□ ICMP Timestamp Echo: Disabling the response to these messages can 
prevent an attacker from being able to reverse engineer some details of your 
network infrastructure. 

□ TCP Window Size: Configures the amount of unacknowledged TCP data 
that the ProxySG can receive before sending an acknowledgement. 

□ PMTU Discovery: Enabling PMTU Discovery prevents packets from being 
unable to reach their destination because they are too large. 

To view the TCP/IP configuration, see "TCP Loss Recovery Mode" on page 408. 
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RFC-1323 

The RFC-1323 TCP/IP option enables the ProxySG to use a set of extensions to 
TCP designed to provide efficient operation over large bandwidth-delay-product 
paths and reliable operation over very high-speed paths, including satellite 
environments. RFC-1323 support can be configured through the CLI and is 
enabled by default. 

To enable or disable RFC-1323 support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip rfc-1323 {enable | disable} 

TCP NewReno 

NewReno is a modification of the Reno algorithm. TCP NewReno improves TCP 
performance during fast retransmit and fast recovery when multiple packets are 
dropped from a single window of data. TCP NewReno support is enabled by 
default. 

To enable or disable TCP NewReno support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip tcp-newreno {enable | disable} 

ICMP Broadcast Echo Support 

Disabling the ICMP broadcast echo command can prevent the ProxySG from 
participating in a Smurf Attack. A Smurf attack is a type of Denial-of-Service 
(DoS) attack, where the attacker sends an ICMP echo request packet to an IP 
broadcast address. This is the same type of packet sent in the ping command, but 
the destination IP is broadcast instead of unicast. If all the hosts on the network 
send echo reply packets to the ICMP echo request packets that were sent to the 
broadcast address, the network is jammed with ICMP echo reply packets, making 
the network unusable. By disabling ICMP broadcast echo response, the ProxySG 
does not participate in the Smurf Attack. 

This setting is disabled by default. 

To enable or disable ICMP broadcast echo support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip icmp-bcast-echo {enable | disable} 

For more information on preventing DDoS attacks, see Chapter 3: "Preventing 
Denial of Service Attacks" on page 79. 

ICMP Timestamp Echo Support 

By disabling the ICMP timestamp echo commands, you can prevent an attacker 
from being able to reverse engineer some details of your network infrastructure. 
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For example, disabling the ICMP timestamp echo commands prevents an attack 
that occurs when the ProxySG responds to an ICMP timestamp request by 
accurately determining the target's clock state, allowing an attacker to more 
effectively attack certain time-based pseudo-random number generators (PRNGs) 
and the authentication systems on which they rely 

This setting is disabled by default. 

To enable or disable ICMP Timestamp echo support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip icmp-timestamp-echo {enable | disable} 

PMTU Discovery 

PMTU (Path Maximum Transmission Unit) is a mechanism designed to discover 
the largest packet size sent that is not fragmented anywhere along the path 
between two communicating appliances that are not directly attached to the same 
link. 

A ProxySG that is not running PMTU might send packets larger than that allowed 
by the path, resulting in packet fragmentation at intermediate routers. Packet 
fragmentation affects performance and can cause packet discards in routers that 
are temporarily overtaxed. 

A ProxySG doing PMTU sets the Do-Not-Fragment bit in the IP header when 
transmitting packets. If fragmentation becomes necessary before the packets 
arrive at the second ProxySG, a router along the path discards the packets and 
returns an icmp Host unreachable error message, with the error condition of 
Needs-Fragmentation, to the original ProxySG appliance. The first appliance then 
reduces the PMTU size and re-transmits the transmissions. 

The discovery period temporarily ends when the ProxySG estimates the PMTU is 
low enough that its packets can be delivered without fragmentation or when the 
ProxySG stops setting the Do-Not-Fragment bit. 

Following discovery and rediscovery, the size of the packets that are transferred 
between the two communicating nodes dynamically adjust to a size allowable by 
the path, which might contain multiple segments of various types of physical 
networks. 

PMTU is disabled by default. 

To configure PMTU discovery: 

At the (config) command prompt: 

SGOS# (config) tcp-ip pmtu-discovery {enable | disable} 



TCP Window Size 

Adjusting the TCP window-size regulates the amount of unacknowledged data 
that the ProxySG receives before sending an acknowledgement. 

To configure the TCP window size: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip window-size window_size 
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where window_size indicates the number of bytes allowed before 
acknowledgement (the value must be between 8192 and 4194304). 



TCP Time Wait 



When a TCP connection is closed (such as when a user enters quit for an FTP 
session), the TCP connection remains in the time wait state for twice the 
Maximum Segment Lifetime (MSL) before completely removing the connection 
control block. 

The time wait state allows an end point (one end of the connection) to remove 
remnant packets from the old connection, eliminating the situation where packets 
from a previous connection are accepted as valid packets in a new connection. 

The MSL defines how long a packet can remain in transit in the network. The 
value of MSL is not standardized; the default value is assigned according to the 
specific implementation. 

To change the MSL value, enter the following commands at the (config) command 
prompt: 

SGOS# (config) tcp-ip tcp-2msl seconds 

where seconds is the length of time you chose for the 2MSL value. Valid 
values are 1 to 16380 inclusive. 



A new TCP algorithm helps to recover throughput efficiently after packet losses 
occur and also addresses performance problems due to a single packet loss during 
a large transfer over long delay pipes. The feature is enhanced by default. 

To enable the algorithm: 

SGOS# (config) tcp-ip tcp-loss-recovery-mode {enhanced | aggressive} 

To disable the algorithm: 

SGOS# (config) tcp-ip tcp-loss-recovery-mode {normal} 



TCP Loss Recovery Mode 



Viewing the TCP/IP Configuration 



To view the TCP/IP configuration: 



SGOS# (config) show tcp-ip 
RFC-1323 support: 

TCP Newreno support: 

IP forwarding: 

ICMP beast echo response: 

ICMP timestamp echo response: 
Path MTU Discovery: 

TCP 2MSL timeout: 

TCP window size: 

TCP Loss Recovery Mode: 



enabled 



disabled 

disabled 

disabled 

disabled 

disabled 



120 seconds 
65535 bytes 
Aggressive 
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This chapter discusses the uses of Virtual IP (VIP) addresses and how to create 
them. 

Virtual IP addresses are addresses assigned to a system (but not an interface) 
that are recognized by other systems on the network. Up to 255 VIPs can be 
configured on each ProxySG appliance. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ "Uses of a VIP" on page 409 

□ "Creating a VIP" on page 409 

Uses of a VIP 

VIP addresses have several uses: 

□ Assign multiple identities to a system on the same or different network, 
partitioning the box in to separate logical entities for resource sharing or 
load sharing. 

□ Create an HTTPS Console to allow multiple, simultaneous, secure 
connections to the system. 

□ Direct authentication challenges to different realms. 

□ Set up failover among multiple ProxySG appliances on the same subnet. 



Note: For information on creating an HTTPS Console, refer to Volume 2: Proxies 
and Proxy Services ; for information on using VIPs with authentication realms, 
refer to Volume 4: Securing the Blue Coat ProxySG Appliance; to use VIPs with 
failover, see Chapter 7: "Configuring Failover" on page 125. 



Creating a VIP 

To create a VIP: 

1. Select Configuration > Network > Advanced > VIPs. 

2. Click New. 

3. Enter the virtual IP address you want to use. It can be any IP address, 
except a multicast address. (A multicast address is a group address, not an 
individual IP address.) 
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Note: You cannot create a VIP address that is the IP address used by the 
origin content server. You must assign a different address on the ProxySG, 
and use DNS or forwarding to point to the origin content server's real IP 
address. 



4. Click OK. 

5. Click Apply. 

The VIP address can now be used. 



Related CLI Syntax to manage a VIP 



SGOS# (config) 
SGOS# (config) 
SGOS# (config) 
SGOS# (config) 



virtual address ip_address 
virtual no address ipaddress 
virtual clear 
show virtual 
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Chapter 1 7; WCCP Settings 



The SGOS software can be configured to participate in a WCCP (Web Cache 
Control Protocol) scheme, in which a WCCP-capable router collaborates with a 
set of WCCP-configured ProxySG appliances to service requests. 

Topics in this Chapter 

This chapter includes information about the following topics: 

□ "Configuring WCCP" on page 411 

□ "Viewing WCCP Statistics and Service Group Status" on page 415 

Configuring WCCP 

WCCP is a Cisco®-developed protocol that allows you to establish redirection 
of the traffic that flows through routers. 



Note: Blue Coat recommends that WCCP-compliant caches from different 
vendors be kept separate and that only one vendor's routers be used in a 
service group. 



One of the caches participating in the WCCP service group is automatically 
elected as the designated cache to configure the home router's redirection 
tables. This way, caches can be transparently added and removed from the 
WCCP service group without requiring operator intervention. WCCP version 2 
supports multiple service groups. 

For detailed information on using WCCP with a ProxySG, refer to the WCCP 
Reference Guide. 

Procedure Overview 

Two tasks must be completed to get WCCP running with the ProxySG: 

□ Configuring the router 

□ Configuring the ProxySG 

WCCP Router Configuration 

1. From the router (config) mode, tell WCCP which service group you want 
use. The Web-cache service group redirects port 80 (HTTP) traffic only. 
Create other service groups to redirect traffic from other ports. 

Router (config) #ip weep web-cache 

2. Enter the (config-if) submode by telling WCCP which IP address to use. 

Router (config) # int interface 
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where interface is the adapter interface with an IP address. The prompt 
changes to configuration interface submode. 

3. Enable packet redirection on the LAN (inbound) interface. 

Router ( config-if) # ip weep web-cache redirect in 

4. If L2 packet return is enabled, prevent those return packets from being 
considered for WCCP redirection by running the following command on the 
interface used to communicate with the ProxySG: 

Router (config-if ) # ip weep redirect exclude in 

For more information on WCCP router configuration, refer to the WCCP Reference 
Guide. 

ProxySG Configuration 

The Management Console provides a text editor that can be used to create the 
configuration file. The ProxySG configuration file is used to tell the Cisco device 
how to use WCCP with this cache (the ProxySG). 



Note: You can also create the file off-box, downloading the file from a 
ProxySG-accessible Web server or uploading the file from a local system. 



An example of a WCCP configuration file is: 

weep enable 
weep version 2 
service-group 9 
forwarding-type L2 
assignment-type mask 
mask-scheme source-port 
priority 1 
protocol 6 

service- flags destination -ip -hash 
service-flags ports-def ined 
ports 80 21 1755 554 0 0 0 0 
interface 0:0 
home-router 10.16.18.2 
end 

For descriptions of the values in the configuration file, refer to the WCCP Reference 
Guide. 

To install the configuration file: 

1. Select Configuration > Network > Advanced >WCCP. 
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2. (Optional): View the WCCP settings that are currently on the system or view 
the text file with the current settings by going to the View WCCP Settings panel 
and clicking WCCP Settings or Source. 

3. In the Install WCCP Settings panel, select the location of the configuration file: a 
remote URL, a local file, or you can use the text editor on the system. 

4. Click Install. 

If you selected Remote URL or Local File, a dialog opens that allows you to enter 
the complete path, and the file is retrieved. 

If you selected Text Editor, the text editor displays with the current settings. You 
can copy and paste the contents of an existing configuration file or you can 
enter new text and click Install when finished. 

5. If the configuration file contains the line weep enable, WCCP is automatically 
enabled when the WCCP configuration is installed. Otherwise, you must 
specifically enable WCCP on the ProxySG. To do this, go the WCCP Statistics 
panel and click Enable WCCP. 



Note: If you enable or disable WCCP, the action is completed immediately. 



6. Click Apply to save the changes. 

To view WCCP status: 

1. Select Configuration > Network > Advanced >WCCP. 
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2. To enable or disable WCCP, click Enable/Disable WCCP. 

3. The current status of the WCCP services are in the pane below the Enable/ 

Disable WCCP button. 

a. You can use Refresh WCCP Statistics to update WCCP statistics. The last 

refresh time is displayed. 

b. Redirected packets, either GRE or Layer 2, are displayed. The 

redirected packets value is reset when WCCP is disabled. 

c. Service Groups: Lists details on the available service groups 

• The Cache IP address is the designated Web cache (the ProxySG with the 
lowest IP address) for the service group. 

• The Router IP address is also the router ID. 

d. State: Displays the availability of the service group. Messages include: 

• Idle: Before the first Here I Am protocol message is sent. 

• Waiting: Here I Am protocol message is sent; waiting for the I See You 
message to be returned. 

• Negotiating: I See You protocol message received. 

• Capability Mismatch: I See You protocol message parsed, but the 
router /ProxySG WCCP capabilities do not match. 

• Packet Porwarding Mismatch: I See You protocol message parsed, but 
a forwarding-type mismatch was found. 

• Packet Return Mismatch: I See You protocol message parsed, but a 
return-type mismatch was found. 
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• Assignment Mismatch: I See You protocol message parsed, but an 
assignment-type mismatch was found. 

• Service Group Mismatch: I See You protocol message parsed, but a 
service-group mismatch was found 

• Security Mismatch: I See You protocol message parsed, but a security 
mismatch was found. 

• Bad Router ID: I See You protocol message parsed, but a bad router ID 
component was found. 

• Bad Router View: I See You protocol message parsed, but a bad router 
view component was found. 

• Ready: Redirect Assignment protocol messages sent. 

e. Protocol messages: Lists the number of packets sent and received: 

• Here I Am: Announces the ProxySG presence to the routers. 

• I See You: Router acknowledges the ProxySG 

• Redirect Assignments: ProxySG sends assignment requests. 

To create a ProxySG WCCP configuration file and enable WCCP using the CLI: 

1. Create a WCCP configuration file through either the ProxySG appliance's CLI 
inline commands or through a text editor. 

2. Make sure that the home router you enter here is the home router that was 
named in the router's configuration. If there is a mismatch, you must correct it 
before continuing. For troubleshooting information, refer to the WCCP 
Reference Guide. 

3. Next steps: 

a. If you used the inline commands, you have completed WCCP 
configuration on the ProxySG. No further steps are needed. 

b. If you used a text editor, copy the file to an HTTP server accessible to 
the ProxySG. Then, enable WCCP and download the configuration file 
to the ProxySG. 

SGOS# (config) weep enable 

SGOS# (config) weep path http://10.25.36.47/files/wccp.txt 
SGOS# (config) load weep-settings 

Viewing WCCP Statistics and Service Group Status 
Viewing WCCP Settings 

You can view the following WCCP statistics through the CLI show weep command 
options: 

□ configuration 

□ statistics 

□ service-group status 
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Configuration 

This command displays the configuration for each service group on the system. 

SGOS# show weep configuration 

;WCCP Settings 
/Version 1 . 3 

weep enable 
weep version 2 
service-group 29 
forwarding-type GRE 
assignment-type hash 
priority 1 
protocol 6 

service-flags source-ip-hash 
service-flags ports-defined 
ports 8080 0000000 
interface 0:0 
home-router 10.25.36.47 
end 



Statistics 



WCCP statistics are repeated for each service group on the system. 



SGOS# show weep statistics 

;WCCP Statistics 
/Version 1.3 



Current time 

Last stats reset time 



: Tue, 
: Tue, 



Mar 11 2008 21:36:40 UTC 
Mar 11 2008 20:21:04 UTC 



Packets sent : 1,37 4 

Bytes sent : 165, 852 

Packet received : 1,342 

Bytes received : 187, 536 

Bad packets received : 0 
Receive error : 0 

Unknown type : 0 

Total size too small :0 
Header too small :0 
Bad version :0 

Bad security comp :0 
Bad service info comp:0 
Bad query info comp : 0 
Unknown group : 0 

Unsolicited query :0 
Bad router id comp : 0 
Bad router view comp:0 



Service group mismatch: 0 
Forwarding type mismatch :0 
Returning type mismatch: 0 
Assignment type mismatch: 0 
Capability mismatch :0 
Bad security packets : 0 



Internal errors : 0 

Failed to send :0 

Add RID for router :0 
Alloc query member :0 
Alloc query timer :0 
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Add router to group : 0 
Add cache to group : 0 
Alloc active caches :0 
Bucket reassignment :0 
Allocated blocks :< 

Service Group ident. 

Home Routers 
Multicast TTL 
Forwarding type 
Returning type 
Assignment type 
Hotspots announced 
Assignment state 
Designated Cache 
Announcement key # 

Cache view change # 

Router View Changed 
Recent hit count 
Primary hit count 
Alternate hit count 
Total ip payload bytes redirected: 0 
Total gre payload bytes redirected: 0 



: 512 , 1 , 2 9, 1,6,17, 

10.25.36.47 
1 

GRE 

GRE 

hash 

0 

idle 

10.25.36.48 
2 



8080,0,0,0,0,0,0,0 



Service Group Status 

Through the CLI, you can view the output of the show weep status command. The 
output is repeated for each service group. 

SGOS> show weep status 

;WCCP Status 
/Version 2 

Number of GRE redirected packets: 0 
Number of Layer 2 redirected packets: 0 

Service group: 9 
State: Ready 

Number of Here_I_Am sent: 514 
Number of I_See_You received: 502 
Number of Redirect_Assign sent: 2 
Router IP: 10.25.36.47 
Cache IP: *10.25.36.48 
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Appendix A: Using Policy to Manage Forwarding 



After ICP, forwarding, and the SOCKS gateways are configured, use policy to 
create and manage forwarding rules. Forwarding, ICP, and SOCKS gateway 
rules should go in the <Forward> layer of the Forwarding Policy file or the VPM 
Policy file (if you use the VPM). 

The separate <Forward> layer is provided because the URL can undergo URL 
rewrites before the request is fetched. This rewritten URL is accessed as a 
server_uri and decisions about upstream connections are based on the 
rewritten URL, requiring a separate layer. All policy commands allowed in the 
<Forward> layer are described below. 



Table A-1 Policy Commands Allowed in the <Forward> Layer 



Forward 


Description 


Conditions 


client address= 


Tests the IP address of the client. Can also be used in 

<Exception> and <Proxy> layers. 


client . host= 


Tests the hostname of the client (obtained through RDNS). 
Can also be used in <Admin>, <Proxy>, and <Exception> 
layers. 


client . host . has name= 


Tests the status of the RDNS performed to determine 

client . host. Can also be used in <Admin>, <Proxy>, and 
<Exception> layers. 


client ,protocol= 


Tests true if the client transport protocol matches the 
specification. Can also be used in <Exception> and 
<Proxy> layers. 


date [ . utc] = 


Tests true if the current time is within the 
startdate..enddate range, inclusive. Can be used in all 
layers. 


day= 


Tests if the day of the month is in the specified range or an 
exact match. Can be used in all layers. 


has client= 


has client= is used to test whether or not the current 
transaction has a client. This can be used to guard triggers 
that depend on client identity. 


hour [ . utc] = 


Tests if the time of day is in the specified range or an exact 
match. Can be used in all layers. 


im. client= 


Tests the type of IM client in use. Can also be used in 

<Proxy>, <Exception>, and <Cache> layers. 


im. message . reflected= 


Tests whether IM reflection occurred. Can also be used in 

<Proxy> and <Cache> layers. 
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Table A-1 Policy Commands Allowed in the <Forward> Layer (Continued) 



Forward 


Description 


minute [ . utc] =month [ . utc] = 


Tests if the minute of the hour is in the specified range or 
an exact match. Can be used in all layers. 


proxy. address= 


Tests the IP address of the network interface card (NIC) on 
which the request arrives. Can also be used in <Admin> 
and <Proxy> layers. 


proxy. card= 


Tests the ordinal number of the network interface card 
(NIC) used by a request. Can also be used in <Admin> and 
<Proxy> layers. 


proxy. port= 


Tests if the IP port used by a request is within the specified 
range or an exact match. Can also be used in <Admin> and 
<Proxy> layers. 


server url [ . case sensitive I .no 
lookup] = 


Tests if a portion of the requested URL exactly matches the 
specified pattern. 


server url.address= 


Tests if the host IP address of the requested URL matches 
the specified IP address, IP subnet, or subnet definition. 


server url . domain [. case sensitive] 
[ . no lookup] = 


Tests if the requested URL, including the domain-suffix 
portion, matches the specified pattern. 


server url . extension [. case 
sensitive] = 


Tests if the filename extension at the end of the path 
matches the specified string. 


server url. host. has name= 


Tests whether the server URL has a resolved DNS 
hostname. 


server url . host [. exact | .substring! 
.prefix! .suffix! .regex] [.no lookup 
] = 


Tests if the host component of the requested URL matches 
the IP address or domain name. 


server url. host. is numeric= 


This is true if the URL host was specified as an IP address. 


server url.host.no name= 


This is true if no domain name can be found for the URL 
host. 


server url . host . regex= 


Tests if the specified regular expression matches a 
substring of the domain name component of the requested 
URL. 


server url. is absolute= 


Tests whether the server URL is expressed in absolute 
form. 


server url . path [. exact | .substring! 
.prefix! .suffix! .regex] 

[.case sensitive] = 


Tests if a prefix of the complete path component of the 
requested URL, as well as any query component, matches 
the specified string. 


server url . path . regex= 


Tests if the regex matches a substring of the path 
component of the request URL. 


server url.port= 


Tests if the port number of the requested URL is within the 
specified range or an exact match. 



420 



Appendix A: Using Policy to Manage Forwarding 



Table A-1 Policy Commands Allowed in the <Forward> Layer (Continued) 



Forward 


Description 


server url . query . regex= 


Tests if the regex matches a substring of the query string 
component of the request URL. 


server url . regex= 


Tests if the requested URL matches the specified pattern. 


server url.scheme= 


Tests if the scheme of the requested URL matches the 
specified string. 


socks= 


This condition is true whenever the session for the current 
transaction involves SOCKS to the client. 


socks . version= 


Switches between SOCKS 4/ 4a and 5. Can also be used in 

<Exception> and <Proxy> layers. 


streaming. client= 


yes I no. Tests the user agent of a Windows, Real Media, 
or QuickTime player. 


time [ . utc] = 


Tests if the time of day is in the specified range or an exact 
match. Can be used in all layers. 


tunneled= 


yes | no. Tests TCP tunneled requests, HTTP CONNECT 
requests, and unaccelerated SOCKS requests 


weekday [ .utc] = 


Tests if the day of the week is in the specified range or an 
exact match. Can be used in all layers. 


year [ . utc] = 


Tests if the year is in the specified range or an exact match. 
Can be used in all layers. 


Properties 




access server)) 


Determines whether the client can receive streaming 
content directly from the OCS. Set to no to serve only 
cached content. 


ftp . transport ( ) 


Determines the upstream transport mechanism. 

This setting is not definitive. It depends on the capabilities 
of the selected forwarding host. 


forward ( ) 


Determines forwarding behavior. 

There is a box-wide configuration setting 
(conf ig>forwarding>failure-mode) for the forward 
failure mode. The optional specific settings can be used to 
override the default. 


forward. fail open)) 


Controls whether the ProxySG appliance terminates or 
continues to process the request if the specified 
forwarding host or any designated backup or default 
cannot be contacted. 


http . ref resh . recv . timeout ( ) 


Sets the socket timeout for receiving bytes from the 
upstream host when performing refreshes. Can also be 
used in <Cache> layers. 
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Table A-1 Policy Commands Allowed in the <Forward> Layer (Continued) 



Forward 


Description 


http. server . connect attempts () 


Sets the number of attempts to connect performed per- 
address when connecting to the upstream host. 


http . server . recv . timeout ( ) 


Sets the socket timeout for receiving bytes from the 
upstream host. Can also be used in <Proxy> layers. 


icp () 


Determines when to consult ICP. The default is yes if ICP 
hosts are configured and if no forwarding host or SOCKS 
gateway is identified as an upstream target. 


im. transport ( ) 


Sets the type of upstream connection to make for IM 
traffic. 


integrate new hosts () 


Determines whether to add new host addresses to health 
checks and load balancing. The default is no. If it is set to 
yes, any new host addresses encountered during DNS 
resolution of forwarding hosts are added to health checks 
and load balancing. 


reflect ip ( ) 


Determines how the client IP address is presented to the 
origin server for explicitly proxied requests. Can also be 
used in <Proxy> layers. 


socks gateway () 


The socks gateway!) property determines the gateway 
and the behavior of the request if the gateway cannot be 
contacted. 

There is a box-wide configuration setting for the SOCKS 
failure mode. The optional specific settings can be used to 
override the default. 


socks gateway. fail open ( ) 


Controls whether the ProxySG terminates or continues to 
process the request if the specified SOCKS gateway or any 
designated backup or default cannot be contacted. 


streaming. transport ( ) 


Determines the upstream transport mechanism. This 
setting is not definitive. The ability to use 
streaming . transport ( ) depends on the capabilities of 
the selected forwarding host. 


trace . request ( ) 


Determines whether detailed trace output is generated for 
the current request. The default value is no, which 
produces no output 


trace . rules ( ) 


Determines whether trace output is generated that shows 
each policy rule that fired. The default value of no 
suppresses output. 


trace . destination ( ) 


Used to change the default path to the trace output file. By 
default, policy evaluation trace output is written to an 
object in the cache accessible using a console URL of the 
following form: 

http: //ProxySG ip address : 8082/ Policy/ 
Trace/path 
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Table A-1 Policy Commands Allowed in the <Forward> Layer (Continued) 



Forward 


Description 


Actions 


notify email ( ) 


Sends an e-mail notification to the list of recipients 
specified in the Event Log mail configuration. Can be used 
in all layers. 


notify snmp ( ) 


The SNMP trap is sent when the transaction terminates. 
Can be used in all layers. 


log message 


Writes the specified string to the event log. 


Definitions 


define server url. domain condition 


Binds a user-defined label to a set of domain suffix 


name 


patterns for use in a condition= expression. 
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Glossary 



access control list — Allows or denies specific IP addresses access to a server. 

access log — A list of all the requests sent to a ProxySG. You can read an access 
log using any of the popular log-reporting programs. When a client uses HTTP 
streaming, the streaming entry goes to the same access log. 

account — A named entity that has purchased the ProxySG or the Entitlements 
from Blue Coat. 

activation code — A string of approximately 10 characters that is generated and 
mailed to customers when they purchase the ProxySG. 

active content stripping — Provides a way to identify potentially dangerous mobile 
or active content and scripts, and strip them out of a response. 

active content types — Used in the Visual Policy Manager. Referring to Web 
Access policies, you can create and name lists of active content types to be 
stripped from Web pages. You have the additional option of specifying a 
customized message to be displayed to the user 

administration access policy — A policy layer that determines who can access the 
ProxySG to perform administrative tasks. 

administration authentication policy — A policy layer that determines how 
administrators accessing the ProxySG must authenticate. 

AJAX — Acronym for Asynchronous JavaScript and XML, the technology used 
for live updating of Web objects without having to reload the entire page. 

Application Delivery Network (ADN) — A WAN that has been optimized for 
acceleration and compression by Blue Coat. This network can also be secured 
through the use of appliance certificates. An ADN network is composed of an 
ADN manager and backup ADN manager, ADN nodes, and a network 
configuration that matches the environment. 

ADN backup manager — Takes over for the ADN manager in the event it becomes 
unavailable. See ADN manager. 

ADN manager — Responsible for publishing the routing table to SG Clients (and 
to other ProxySG appliances). 

ADN optimize attribute — Controls whether to optimize bandwidth usage when 
connecting upstream using an ADN tunnel. 

A record — The central records of DNS, which link a domain or subdomain to an 
IP address. An A record can correspond to a single IP address or many IP 
addresses. 

asx rewrite — Allows you to rewrite URLs and then direct a client's subsequent 
request to the new URL. One of the main applications of ASX file rewrites is to 
provide explicit proxy-like support for Windows Media Player 6.4, which 
cannot set explicit proxy mode for protocols other than HTTP. 
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audit — A log that provides a record of who accessed what and how. 

authenticate-401 attribute — All transparent and explicit requests received on the port 
always use transparent authentication (cookie or IP, depending on the 
configuration). This is especially useful to force transparent proxy authentication 
in some proxy-chaining scenarios 

authenticated content — Cached content that requires authentication at the origin 
content server (OCS). Supported authentication types for cached data include 
basic authentication and IWA (or NTLM). 

authentication — Allows you to verify the identity of a user. In its simplest form, this 
is done through usernames and passwords. Much more stringent authentication 
can be employed using digital certificates that have been issued and verified by a 
Certificate Authority. See also basic authentication, proxy authentication, and SSL 
authentication. 

authentication realm — Authenticates and authorizes users to access SG services 
using either explicit proxy or transparent proxy mode. These realms integrate 
third-party vendors, such as LDAP, Windows, and Novell, with the Blue Coat 
operating system. 

authorization — The permissions given to an authenticated user. 



bandwidth — The amount of data you can send through a network or modem 
connection, usually measured in bits per second (bps). 

bandwidth class — A defined unit of bandwidth allocation. 

bandwidth class hierarchy — A gouping of bandwidth classes into a tree structure 
that specifies the relationship among different classes. You create a hierarchy by 
creating at least one parent class and assigning other classes as its children. 

bandwidth gain — Bandwidth gain is a calculation of the savings that occur when 
bandwidth is not consumed as a result of some form of optimization. 

For example, bandwidth gain for active sessions is calculated by subtracting the 
number of client bytes from the number of server bytes and dividing the result by 
the number of server bytes. 

(Client Bytes - Server Bytes) / Server Bytes 

bandwidth management — Classify, control, and, if needed, limit the amount of 
bandwidth used by network traffic flowing in or out of a ProxySG. 

basic authentication — The standard authentication for communicating with the 
target as identified in the URL. 

BCAAA — Blue Coat Authentication and Authorization Agent. Allows SGOS 5.x to 
manage authentication and authorization for IWA, CA eTrust SiteMinder realms, 
Oracle COREid, Novell, and Windows realms. The agent is installed and 
configured separately from SGOS 5.x and is available from the Blue Coat Web site. 

BCLP — Blue Coat Licensing Portal. 

byte-range support — The ability of the ProxySG to respond to byte-range requests 
(requests with a Range : HTTP header). 
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cache — An "object store," either hardware or software, that stores information 
(objects) for later retrieval. The first time the object is requested, it is stored, 
making subsequent requests for the same information much faster. 

A cache helps reduce the response time and network bandwidth consumption on 
future, equivalent requests. The ProxySG serves as a cache by storing content 
from many users to minimize response time and prevent extraneous network 
traffic. 

cache control — Allows you to configure which content the ProxySG stores. 

cache efficiency — A tab found on the Statistics pages of the Management Console 
that shows the percent of objects served from cache, the percent loaded from the 
network, and the percent that were non-cacheable. 

cache hit — Occurs when the ProxySG receives a request for an object and can serve 
the request from the cache without a trip to the origin server. 

cache miss — Occurs when the ProxySG receives a request for an object that is not 
in the cache. The ProxySG must then fetch the requested object from the origin 
server. 

cache object — Cache contents includes all objects currently stored by the ProxySG. 
Cache objects are not cleared when the ProxySG is powered off. 

Certificate Authority (CA) — A trusted, third-party organization or company that 
issues digital certificates used to create digital signatures and public key/ private 
key pairs. The role of the CA is to guarantee that the individuals or company 
representatives who are granted a unique certificate are who they claim to be. 

child class (bandwidth gain) — The child of a parent class is dependent on that parent 
class for available bandwidth (they share the bandwidth in proportion to their 
minimum/ maximum bandwidth values and priority levels). A child class with 
siblings (classes with the same parent class) shares bandwidth with those siblings 
in the same manner. 

cipher suite — Specifies the algorithms used to secure an SSL connection. When a 
client makes an SSL connection to a server, it sends a list of the cipher suites that it 
supports. 

client consent certificates — A certificate that indicates acceptance or denial of 
consent to decrypt an end user's HTTPS request. 

client-side transparency — A way of replacing the ProxySG IP address with the Web 
server IP address for all port 80 traffic destined to go to the client. This effectively 
conceals the ProxySG address from the client and conceals the identity of the 
client from the Web server. 

concentrator — A ProxySG, usually located in a data center, that provides access to 
data center resources, such as file servers. 

content filtering — A way of controlling which content is delivered to certain users. 
ProxySG appliances can filter content based on content categories (such as 
gambling, games, and so on), type (such as http, ftp, streaming, and mime type), 
identity (user, group, network), or network conditions. You can filter content 
using vendor-based filtering or by allowing or denying access to URLs. 
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default boot system — The system that was successfully started last time. If a system 
fails to boot, the next most recent system that booted successfully becomes the 
default boot system. 

default proxy listener — See proxy service (default). 

denial of service (DoS) — A method that hackers use to prevent or deny legitimate 
users access to a computer, such as a Web server. DoS attacks typically send many 
request packets to a targeted Internet server, flooding the server's resources and 
making the system unusable. Any system connected to the Internet and equipped 
with TCP-based network services is vulnerable to a DoS attack. 

The ProxySG resists DoS attacks launched by many common DoS tools. With a 
hardened TCP/IP stack, the ProxySG resists common network attacks, including 
traffic flooding. 

destination objects — Used in Visual Policy Manager. These are the objects that 
define the target location of an entry type. 

detect protocol attribute — Detects the protocol being used. Protocols that can be 
detected include: HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and 
Endpoint Mapper. 

diagnostic reporting — Found in the Statistics pane, the Diagnostics tab allows you to 
control whether Daily Heartbeats and/ or Blue Coat Monitoring are enabled or 
disabled. 

directives — Commands used in installable lists to configure forwarding and 
SOCKS gateway. 

DNS access — A policy layer that determines how the ProxySG processes DNS 
requests. 

domain name system (DNS) — An Internet service that translates domain names into 
IP addresses. 

dynamic bypass — Provides a maintenance-free method for improving performance 
of the ProxySG by automatically compiling a list of requested URLs that return 
various kinds of errors. 

dynamic real-time rating (DRTR) — Used in conjunction with the Blue Coat Web Filter 
(BCWF), DRTR (also known as dynamic categorization) provides real-time analysis 
and content categorization of requested Web pages to solve the problem of new 
and previously unknown uncategorized URLs — those not in the database. 

When a user requests a URL that has not already been categorized by the BCWF 
database (for example, a brand new Web site), the ProxySG dynamic 
categorization service analyzes elements of the requested content and assigns a 
category or categories. The dynamic service is consulted only when the installed 
BCWF database does not contain category information for an object. 



early intercept attribute — Controls whether the proxy responds to client TCP 
connection requests before connecting to the upstream server. When early 
intercept is disabled, the proxy delays responding to the client until after it has 
attempted to contact the server. 
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ELFF-compatible format — A log type defined by the W3C that is general enough to 
be used with any protocol. 

emulated certificates — Certificates that are presented to the user by the ProxySG 
when intercepting HTTPS requests. Blue Coat emulates the certificate from the 
server and signs it, copying the subjectName and expiration. The original 
certificate is used between the ProxySG and the server. 

encrypted log — A log is encrypted using an external certificate associated with a 
private key. Encrypted logs can only be decrypted by someone with access to the 
private key. The private key is not accessible to the ProxySG. 

EU LA — End user license agreement. 

event logging — Allows you to specify the types of system events logged, the size of 
the event log, and to configure Syslog monitoring. The ProxySG can also notify 
you by email if an event is logged. See also access logging. 

explicit proxy — A configuration in which the browser is explicitly configured to 
communicate with the proxy server for access to content. This is the default for 
the ProxySG and requires configuration for both the browser and the interface 
card. 

extended log file format (ELFF) — A variant of the common log file format, which has 
two additional fields at the end of the line — the referer and the user agent fields. 



fail open/closed — Failing open or closed applies to forwarding hosts and groups 
and SOCKS gateways. Fail open or closed applies when health checks are 
showing sick for each forwarding or SOCKS gateway target in the applicable fail- 
over sequence. If no systems are healthy, the ProxySG fails open or closed, 
depending on the configuration. If closed, the connection attempt simply fails. 

If open, an attempt is made to connect without using any forwarding target (or 
SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no 
setting is specified. 

filtering — See content filtering. 

forward proxy — A proxy server deployed close to the clients and used to access 
many servers. A forward proxy can be explicit or transparent. 

FTP — See Native FTP and Web FTP. 



gateway — A device that serves as entrance and exit into a communications 
network. 



hardware serial number — A string that uniquely identifies the ProxySG; it is assigned 
to each unit in manufacturing. 

health check tests — The method of determining network connectivity, target 
responsiveness, and basic functionality. The following tests are supported: 
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• ICMP 

• TCP 

• SSL 

• HTTP 

• HTTPS 

• Group 

• Composite and reference to a composite result 

• ICAP 

• Websense 

• DRTR rating service 

health check type — The kind of device or service the specific health check tests. The 
following types are supported: 

• Forwarding host and forwarding group 

• SOCKS gateway and SOCKS gateway group 

• CAP service and ICAP service group 

• Websense off-box service and Websense off-box service group 

• DRTR rating service 

• User-defined host and a user-defined composite 

heartbeat — Messages sent once every 24 hours that contain the statistical and 
configuration data for the ProxySG, indicating its health. Heartbeats are 
commonly sent to system administrators and to Blue Coat. Heartbeats contain no 
private information, only aggregate statistics useful for pre-emptively diagnosing 
support issues. 

The ProxySG sends emergency heartbeats whenever it is rebooted. Emergency 
heartbeats contain core dump and restart flags in addition to daily heartbeat 
information. 

host affinity — The attempt to direct multiple connections by a single user to the 
same group member. Host affinity is closely tied to load balancing behavior; both 
should be configured if load balancing is important. 

host affinity timeout — The host affinity timeout determines how long a user remains 
idle before the connection is closed. The timeout value checks the user's IP 
address, SSL ID, or cookie in the host affinity table. 



inbound traffic (bandwidth gain) — Network packets flowing into the ProxySG. 
Inbound traffic mainly consists of the following: 

• Server inbound: Packets originating at the origin content server (OCS) and 
sent to the ProxySG to load a Web object. 
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• Client inbound: Packets originating at the client and sent to the ProxySG 
for Web requests. 

installable list — A list of configuration parameters that can be created using a text 
editor (either Blue Coat or another text editor) or through the CLI inline 
commands. The list can then be downloaded to the ProxySG from an HTTP server 
or locally from your PC. Configurations that can be created and installed this way 
include the SG Client, archiving, forwarding hosts, SOCKS gateways, ICP, policy 
files, and exceptions. 

integrated host timeout — An integrated host is an origin content server (OCS) that 
has been added to the health check list. The host, added through the 
integrate_new_hosts property, ages out of the integrated host table after 
being idle for the specified time. The default is 60 minutes. 

intervals — Time period from the completion of one health check to the start of the 
next health check. 

IP reflection — Determines how the client IP address is presented to the origin server 
for explicitly proxied requests. All proxy services contain a reflect-ip attribute, 
which enables or disables sending of client's IP address instead of the IP address 
of the ProxySG. 

issuer keyring — The keyring used by the ProxySG to sign emulated certificates. The 
keyring is configured on the appliance and managed through policy. 



licensable component (LC) — (Software) A subcomponent of a license; it is an option 
that enables or disables a specific feature. 

LCAMS — License Configuration and Management System. 

license — Provides both the right and the ability to use certain software functions 
within a Proxy AV (or ProxySG) appliance. The license key defines and controls 
the license, which is owned by an account. 

listener — The service that is listening on a specific port. A listener can be identified 
by any destination IP/subnet and port range. Multiple listeners can be added to 
each service. 

live content — Also called live broadcast. Used in streaming, it indicates that the 
content is being delivered fresh. 

LKF — License key file. 

load balancing — A way to share traffic requests among multiple upstream systems 
or multiple IP addresses on a single host. 

local bypass list — A list you create and maintain on your network. You can use a 
local bypass list alone or in conjunction with a central bypass list. 

local policy file — Written by enterprises (as opposed to the central policy file written 
by Blue Coat); used to create company- and department-specific advanced 
policies written in the Blue Coat Policy Language (CPL). 
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log facility — A separate log that contains a single logical file and supports a single 
log format. It also contains the file's configuration and upload schedule 
information as well as other configurable information such as how often to rotate 
(switch to a new log) the logs at the destination, any passwords needed, and the 
point at which the facility can be uploaded. 

log format — The type of log that is used: NCSA/ Common, SQUID, ELFF, 
SurfControl, or Websense. 

The proprietary log types each have a corresponding pre-defined log format that 
has been set up to produce exactly that type of log (these logs cannot be edited). In 
addition, a number of other EFFF type log formats are also pre-defined (im, main, 
p2p, ssl, streaming). These can be edited, but they start out with a useful set of log 
fields for logging particular protocols understood by the ProxySG. It is also 
possible to create new log formats of type EFFF or Custom which can contain any 
desired combination of log fields. 

log tail — The access log tail shows the log entries as they get logged. With high 
traffic on the ProxySG, not all access log entries are necessarily displayed. 
However, you can view all access log information after uploading the log. 



M 

MACH5 — SGOS 5 MACH5 Edition. 

Management Console — A graphical Web interface that lets you to manage, 
configure, monitor, and upgrade the ProxySG from any location. The 
Management Console consists of a set of Web pages and Java applets stored on 
the ProxySG. The appliance acts as a Web server on the management port to serve 
these pages and applets. 

management information base (MIB) — Defines the statistics that management systems 
can collect. A managed device (gateway) has one or more MIBs as well as one or 
more SNMP agents, which implements the information and management 
functionality defined by a specific MIB. 

maximum object size — The maximum object size stored in the ProxySG. All objects 
retrieved that are greater than the maximum size are delivered to the client but are 
not stored in the ProxySG. 

Media Access Control (MAC) address — A unique value associated with a network 
adapter; also known as hardware address or physical address. For the ProxySG, it 
is a hardware address that is stored in each network card (such as an SSF 
accelerator card or a Quad GigE Fiber EX card) on the ProxySG. The MAC 
address uniquely identifies an adapter on a FAN and is a 12-digit hexadecimal 
number (48 bits in length). 

MIME/FILE type filtering — Allows organizations to implement Internet policies for 
both uploaded and downloaded content by MIME or FIFE type. 

multi-bit rate — The capability of a single stream to deliver multiple bit rates to 
clients requesting content from ProxySG appliances from within varying levels of 
network conditions (such as different connecting band widths and traffic). 

multicast — Used in streaming; the ability for hundreds or thousands of users to 
play a single stream. 
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multicast aliases — Used in streaming; a streaming command that specifies an alias 
for a multicast URL to receive an .nsc file. The .nsc files allows the multicast 
session to obtain the information in the control channel 

multicast station — Used in streaming; a defined location on the proxy where the 
Windows Media player can retrieve streams. A multicast station enables multicast 
transmission of Windows Media content from the cache. The source of the 
multicast-delivered content can be a unicast-live source, a multicast (live) source, 
and simulated live (video-on-demand content converted to scheduled live 
content). 

multimedia content services — Used in streaming; multimedia support includes Real 
Networks, Microsoft Windows Media, Apple QuickTime, MP3, and Flash. 



name inputing — Allows a ProxySG to resolve host names based on a partial name 
specification. When a host name is submitted to the DNS server, the DNS server 
resolves the name to an IP address. If the host name cannot be resolved. Blue Coat 
adds the first entry in the name-inputing list to the end of the host name and 
resubmits it to the DNS server 

native FTP — Native FTP involves the client connecting (either explicitly or 
transparently) using the FTP protocol; the ProxySG then connects upstream 
through FTP (if necessary). 

NCSA common log format — Blue Coat products are compatible with this log type, 
which contains only basic HTTP access information. 

network address translation (NAT) — The process of translating private network (such 
as intranet) IP addresses to Internet IP addresses and vice versa. This 
methodology makes it possible to match private IP addresses to Internet IP 
addresses even when the number of private addresses outnumbers the pool of 
available Internet addresses. 

non-cacheable objects — A number of objects are not cached by the ProxySG because 
they are considered non-cacheable. You can add or delete the kinds of objects that 
the appliance considers non-cacheable. Some of the non-cacheable request types 
are: 

• Pragma no-cache, requests that specify non-cached objects, such as when 
you click refresh in the Web browser. 

• Password provided, requests that include a client password. 

• Data in request that include additional client data. 

• Not a GET request. 

.nsc file — Created from the multicast station definition and saved through the 
browser as a text file encoded in a Microsoft proprietary format. Without an .nsc 
file, the multicast station definition does not work. 
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NTP — To manage objects in an appliance, a ProxySG must know the current 
Universal Time Coordinates (UTC) time. By default, the ProxySG attempts to 
connect to a Network Time Protocol (NTP) server to acquire the UTC time. The 
ProxySG includes a list of NTP servers available on the Internet, and attempts to 
connect to them in the order they appear in the NTP server list on the NTP tab. 



object (used in caching) — An object is the item that is stored in an appliance. These 
objects can be frequently accessed content, content that has been placed there by 
content publishers, or Web pages, among other things. 

object (used in Visual Policy Manager) — An object (sometimes referred to as a 
condition) is any collection or combination of entry types you can create 
individually (user, group, IP address/ subnet, and attribute). To be included in an 
object, an item must already be created as an individual entry. 

object pipelining — This patented algorithm opens as many simultaneous TCP 
connections as the origin server will allow and retrieves objects in parallel. The 
objects are then delivered from the appliance straight to the user's desktop as fast 
as the browser can request them. 

Online Certificate Status Protocol (OCSP) — An Internet protocol used for obtaining the 
revocation status of an X.509 digital certificate. OCSP was created as an 
alternative to certificate revocation lists (CRL), specifically addressing certain 
problems associated with using CRLs in a public key infrastructure (PKI). OCSP 
servers are called OCSP responders due to the request/ response nature of these 
messages. 

origin content server (OCS) — Also called origin server. This is the original source of 
the content that is being requested. An appliance needs the OCS to acquire data 
the first time, to check that the content being served is still fresh, and to 
authenticate users. 

outbound traffic (bandwidth gain) — Network packets flowing out of the ProxySG. 
Outbound traffic mainly consists of the following: 

• Client outbound: Packets sent to the client in response to a Web request. 

• Server outbound: Packets sent to an OCS or upstream proxy to request a 
service. 



PAC (Proxy AutoConfiguration) scripts — Originally created by Netscape, PACs are a 
way to avoid requiring proxy hosts and port numbers to be entered for every 
protocol. You need only enter the URL. A PAC can be created with the needed 
information and the local browser can be directed to the PAC for information 
about proxy hosts and port numbers. 

packet capture (PCAP) — Allows filtering on various attributes of the Ethernet frame 
to limit the amount of data collected. You can capture packets of Ethernet frames 
going into or leaving a ProxySG. 
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parent class (bandwidth gain) — A class with at least one child. The parent class must 
share its bandwidth with its child classes in proportion to the minimum/ 
maximum bandwidth values or priority levels. 

passive mode data connections (PASV) — Data connections initiated by an FTP client to 
an FTP server. 

pipelining — See object pipelining. 

policies — Groups of rules that let you manage Web access specific to the needs of 
an enterprise. Policies enhance ProxySG feature areas such as authentication and 
virus scanning, and let you control end-user Web access in your existing 
infrastructure. 

policy-based bypass list — Used in policy. Allows a bypass based on the properties of 
the client, unlike static and dynamic bypass lists, which allow traffic to bypass the 
appliance based on destination IP address. See also dynamic bypass. 

policy layer — A collection of rules created using Blue Coat CPL or with the VPM. 

pragma: no cache (PNC) — A metatag in the header of a request that requires the 
appliance to forward a request to the origin server. This allows clients to always 
obtain a fresh copy. 

proxy — Caches content, filters traffic, monitors Internet and intranet resource 
usage, blocks specific Internet and intranet resources for individuals or groups, 
and enhances the quality of Internet or intranet user experiences. 

A proxy can also serve as an intermediary between a Web client and a Web server 
and can require authentication to allow identity-based policy and logging for the 
client. 

The rules used to authenticate a client are based on the policies you create on the 
ProxySG, which can reference an existing security infrastructure — LDAP, 
RADIUS, IWA, and the like. 

Proxy Edition — SGOS 5 Proxy Edition. 

proxy service — The proxy service defines the ports, as well as other attributes, that 
are used by the proxies associated with the service. 

proxy service (default) — The default proxy service is a service that intercepts all 
traffic not otherwise intercepted by other listeners. It only has one listener whose 
action can be set to bypass or intercept. No new listeners can be added to the 
default proxy service, and the default listener and service cannot be deleted. 
Service attributes can be changed. 

ProxySG — A Blue Coat security and cache box that can help manage security and 
content on a network. 

public key certificate — An electronic document that encapsulates the public key of 
the certificate sender, identifies this sender, and aids the certificate receiver to 
verify the identity of the certificate sender. A certificate is often considered valid if 
it has been digitally signed by a well-known entity, which is called a Certificate 
Authority (such as VeriSign). 

public virtual IP (VIP) — Maps multiple servers to one IP address and then propagates 
that information to the public DNS servers. Typically, there is a public VIP known 
to the public Internet that routes the packets internally to the private VIP. This 
enables you to "hide" your servers from the Internet. 
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real-time streaming protocol (RTSP) — A standard method of transferring audio and 
video and other time-based media over Internet-technology based networks. The 
protocol is used to stream clips to any RTP-based client. 

reflect client IP attribute — Enables the sending of the client's IP address instead of the 
SG's IP address to the upstream server. If you are using an application delivery 
network (ADN), this setting is enforced on the concentrator proxy through the 

Configuration > App. Delivery Network > Tunneling tab. 

registration — An event that binds the appliance to an account, that is, it creates the 
Serial#, Account association. 

remote authentication dial-in user service (RADIUS) — Authenticates user identity via 
passwords for network access. 

Return to Sender (RTS) — A way of allowing outgoing TCP packets to use the same 
network interface on which the corresponding incoming TCP packets arrived. 
The destination Media Acess Control (MAC) address for the outgoing packets is 
the same as the source MAC address of the incoming packets. See also Media 
Access Control (MAC) address. 

reverse proxy — A proxy that acts as a front end to a small number of predefined 
servers, typically to improve performance. Many clients can use it to access the 
small number of predefined servers. 

routing information protocol (RIP) — Designed to select the fastest route to a 
destination. RIP support is built into ProxySG appliances. 

router hops — The number of jumps a packet takes when traversing the Internet. 
RTS — See Return to Sender. 



secure shell (SSH) — Also known as Secure Socket Shell. SSH is an interface and 
protocol that provides strong authentication and enables you to securely access a 
remote computer. Three utilities — login, ssh, and scp — comprise SSH. Security via 
SSH is accomplished using a digital certificate and password encryption. 
Remember that the Blue Coat ProxySG requires SSH1. A ProxySG supports a 
combined maximum of 16 Telnet and SSH sessions. 

serial console — A third-party device that can be connected to one or more Blue 
Coat appliances. Once connected, you can access and configure the appliance 
through the serial console, even when you cannot access the appliance directly. 

server certificate categories — The hostname in a server certificate can be categorized 
by BCWF or another content filtering vendor to fit into categories such as 
banking, finance, sports. 

server portals — Doorways that provide controlled access to a Web server or a 
collection of Web servers. You can configure Blue Coat appliances to be server 
portals by mapping a set of external URLs onto a set of internal URLs. 
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server-side transparency — The ability for the server to see client IP addresses, which 
enables accurate client-access records to be kept. When server-side transparency 
is enabled, the appliance retains client IP addresses for all port 80 traffic to and 
from the ProxySG. In this scheme, the client IP address is always revealed to the 
server. 

service attributes — Define the parameters, such as explicit or transparent, cipher 
suite, and certificate verification, that the ProxySG uses for a particular service. 

sibling class (bandwidth gain) — A bandwidth class with the same parent class as 
another class. 

signed system image — Cryptographically signed with a key known only to Blue 
Coat, and the signature is verified when the image is downloaded to the system. 

simple network management protocol (SNMP) — The standard operations and 
maintenance protocol for the Internet. It consists of a set of standards for network 
management, including an application layer protocol, a database schema, and a 
set of data objects. In SNMP, the available information is defined by management 
information bases (MIBs), which describe the structure of the management data. 

simulated live — Used in streaming. Defines playback of one or more video-on- 
demand files as a scheduled live event, which begins at a specified time. The 
content can be looped multiple times, or scheduled to start at multiple start times 
throughout the day. 

SmartReporter log type — A proprietary ELFF log type that is compatible with the 
SmartFilter SmartReporter tool. 

SOCKS — A proxy protocol for TCP/IP-based networking applications that allows 
users transparent access across the firewall. If you are using a SOCKS server for 
the primary or alternate forwarding gateway, you must specify the appliance's ID 
for the identification protocol used by the SOCKS gateway. The machine ID 
should be configured to be the same as the appliance's name. 

SOCKS proxy — A generic way to proxy TCP and UDP protocols. The ProxySG 
supports both SOCKSv4/ 4a and SOCKSv5; however, because of increased 
username and password authentication capabilities and compression support. 
Blue Coat recommends that you use SOCKS v5. 

splash page — The custom message page that displays the first time you start the 
client browser. 

split proxy — Employs co-operative processing at the branch and the core to 
implement functionality that is not possible in a standalone proxy. Examples of 
split proxies include: 

• Mapi Proxy 

• SSE Proxy 

SQUID-compatible format — A log type that was designed for cache statistics and is 
compatible with Blue Coat products. 

squid-native log format — The Squid-compatible format contains one line for each 
request. 

SSL authentication — Ensures that communication is with "trusted" sites only. 
Requires a certificate issued by a trusted third party (Certificate Authority). 
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SSL client — See SSL device profile. 

SSL device profile — Used to determine various SSL parameters for outgoing HTTPS 
connections. Specifically, its role is to: 

• Identify the SSL protocol version that the ProxySG uses in negotiations 
with origin servers. 

• Identify the cipher suites used. 

• Determine which certificate can be presented to origin servers by 
associating a keyring with the profile. 

SSL interception — Decrypting SSL connections. 

SSL proxy — A proxy that can be used for any SSL traffic (HTTPS or not), in either 
forward or reverse proxy mode. 

static route — A manually-configured route that specifies the transmission path a 
packet must follow, based on the packet's destination address. A static route 
specifies a transmission path to another network. 

statistics — Every Blue Coat appliance keeps statistics of the appliance hardware 
and the objects it stores. You can review the general summary, the volume, 
resources allocated, cache efficiency, cached contents, and custom URLs generated 
by the appliance for various kinds of logs. You can also check the event viewer for 
every event that occurred since the appliance booted. 

stream — A flow of a single type of data, measured in kilobits per second (Kbps). A 
stream could be the sound track to a music video, for example. 

SurfControl log type — A proprietary log type that is compatible with the SurfControl 
reporter tool. The SurfControl log format includes fully-qualified usernames 
when an NTLM realm provides authentication. The simple name is used for all 
other realm types. 

syslog — An event-monitoring scheme that is especially popular in Unix 
environments. Most clients using Syslog have multiple devices sending messages 
to a single Syslog daemon. This allows viewing a single chronological event log of 
all of the devices assigned to the Syslog daemon. The Syslog format is: "Date Time 
Hostname Event." 

system cache — The software cache on the appliance. When you clear the cache, all 
objects in the cache are set to expired. The objects are not immediately removed 
from memory or disk, but a subsequent request for any object requested is 
retrieved from the origin content server before it is served. 



TCP window size — The number of bytes that can be buffered before the sending host 
must wait for an acknowledgement from the receiving host. 

time-to-live (TTL) value — Used in any situation where an expiration time is needed. 
For example, you do not want authentication to last beyond the current session 
and also want a failed command to time out instead of hanging the box forever. 

traffic flow (bandwidth gain) — Also referred to as flow. A set of packets belonging to 
the same TCP/UDP connection that terminate at, originate at, or flow through the 
ProxySG. A single request from a client involves two separate connections. One of 
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them is from the client to the ProxySG, and the other is from the ProxySG to the 
OCS. Within each of these connections, traffic flows in two directions — in one 
direction, packets flow out of the ProxySG (outbound traffic), and in the other 
direction, packets flow into the ProxySG (inbound traffic). Connections can come 
from the client or the server. Thus, traffic can be classified into one of four types: 

• Server inbound 

• Server outbound 

• Client inbound 

• Client outbound 

These four traffic flows represent each of the four combinations described above. 
Each flow represents a single direction from a single connection. 

transmission control protocol (TCP) — TCP, when used in conjunction with IP (Internet 
Protocol) enables users to send data, in the form of message units called packets, 
between computers over the Internet. TCP is responsible for tracking and 
handling, and reassembly of the packets; IP is responsible for packet delivery. 

transparent proxy — A configuration in which traffic is redirected to the ProxySG 
without the knowledge of the client browser. No configuration is required on the 
browser, but network configuration, such as an L4 switch or a WCCP-compliant 
router, is required. 

trial period — Starting with the first boot, the trial period provides 60 days of free 
operation. All features are enabled during this time. 



unicast alias — Defines an name on the appliance for a streaming URL. When a 
client requests the alias content on the appliance, the appliance uses the URL 
specified in the unicast-alias command to request the content from the origin 
streaming server. 

universal time coordinates (UTC) — A ProxySG must know the current UTC time. By 
default, the appliance attempts to connect to a Network Time Protocol (NTP) 
server to acquire the UTC time. If the ProxySG cannot access any NTP servers, 
you must manually set the UTC time. 

URL filtering — See content filtering. 

URL rewrite rules — Rewrite the URLs of client requests to acquire the streaming 
content using the new URL. Lor example, when a client tries to access content on 
www.mycompany.com, the ProxySG is actually receiving the content from the 
server on 10.253.123.123. The client is unaware that mycompany.com is not 
serving the content; however, the ProxySG access logs indicate the actual server 
that provides the content. 



WCCP — Web Cache Communication Protocol. Allows you to establish redirection 
of the traffic that flows through routers. 
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Web FTP — Web FTP is used when a client connects in explicit mode using HTTP 
and accesses an ftp:/ / URL. The ProxySG translates the HTTP request into an 
FTP request for the OCS (if the content is not already cached), and then translates 
the FTP response with the file contents into an HTTP response for the client. 

Websense log type — A Blue Coat proprietary log type that is compatible with the 
Websense reporter tool. 



XML responder — HTTP XML service that runs on an external server. 

XML requestor — XML realm. 
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